Agent-Computer Interface（智能体计算机接口）

ACI（Agent-Computer Interface，智能体计算机接口） 是由 SWE-agent 论文（Yang et al., Princeton/CMU, 2024）正式提出的概念，将 AI Agent（智能体）与计算机系统的交互接口，类比为人机交互中的 HCI（Human-Computer Interface）来设计和优化。

核心论点：专为 Agent 设计的接口（而非直接复用人类 UI 或通用 API）能大幅提升 Agent 性能，且无需修改模型权重本身。Anthropic 在《Building Effective Agents》中也使用了这一框架，强调工具定义和工具文档应与 prompt 获得同等量级的工程关注。

为什么 ACI 重要

Agent 调用工具时，工具的定义（参数名、类型、描述）和说明文档，就是 Agent 的"用户界面"。设计得差的工具接口会导致 Agent 频繁误用——就像设计得差的 UI 会让用户频繁出错。

Anthropic 在自己的 SWE-bench Agent 实现中发现：他们花在优化工具上的时间比花在整体 prompt 上还多。一个具体例子：Agent 使用相对路径后切换目录会出错，把工具改为强制要求绝对路径后，错误消失。

OpenAI 的 Agent 构建指南也从生产角度强调同一件事：工具应有标准化定义，便于一个工具被多个 Agent 复用、测试、发现和版本管理。文档清楚、参数稳定、语义不重叠的工具，能减少模型在工具选择上的不确定性；工具数量增加时，优先改进命名、参数和描述，仍然不稳定时再拆分多 Agent。

Anthropic 后续在《Writing effective tools for agents – with agents》中把这个判断推进到更具体的工具工程：不要把工具当成后端 API 端点的直译，而要当成 Agent 的操作界面。工具集合应该贴近真实工作流，减少无意义的中间输出，把常见多步链路封装进高层动作，并用 eval trace 反复检查 Agent 实际在哪里误解了接口。

ACI 设计原则

1. 站在模型的视角想

读一遍你的工具定义：光看描述和参数，是否能直觉上明白这个工具怎么用？如果你需要仔细想一想，模型也一样。

好的工具定义通常包含：

典型使用示例
边界情况说明
输入格式要求
与其他相似工具的区别

2. 像给初级工程师写文档一样写工具描述

参数名和描述是 Agent 理解工具的唯一渠道。对相似工具尤其重要——当有多个工具做相近的事，模型需要靠文档区分它们。

3. 测试模型如何使用你的工具

用大量示例输入运行，观察模型在哪里出错，迭代改进工具定义。

这里的“测试”不只是看工具函数能否执行，而是看 Agent 能否在真实任务中选对工具、传对参数、读懂响应并完成目标。Anthropic 建议用真实业务数据构造多步 eval：记录准确率、工具调用次数、工具错误、token 消耗和运行时间，再从 trace 中定位工具描述、schema、分页默认值或输出格式的问题。

4. Poka-Yoke（防错设计）

从接口设计上减少出错可能：参数设计成难以误用的形状，而不是在文档里叮嘱"小心别出错"。

Anthropic 的例子：

要求绝对路径而非相对路径（防止 Agent 切换目录后路径失效）
用枚举值替代自由字符串（防止格式不一致）
分离"读"和"写"操作（防止 Agent 在本想只读时意外写入）

工具格式选择

工具格式影响 Agent 的表现：

给模型足够的 token “思考”：不要让工具格式逼着模型在写出答案前就必须确定某个数值（如 diff 的行号必须在看到新代码前就写对）
贴近互联网上自然出现的格式：让模型能利用训练数据中的模式识别
避免格式"税"：不要要求模型维护一个精确的行数计数器，或把代码写进 JSON（需要额外转义换行和引号）

例如，用 diff 格式指定文件修改，要求模型在写新代码前就确定准确的 chunk header（多少行改变），而直接重写文件内容的格式则没有这个负担。

OpenAI 的 Codex Prompting Guide 给了 coding-agent 场景的同类例子：工具名、参数名和输出形状应尽量贴近模型熟悉的终端与 codex-cli 经验。比如 shell 工具显式要求 workdir，比让模型在命令字符串里 cd 更少隐式状态；计划工具用 pending、in_progress、completed 等枚举，比自由文本状态更容易稳定解析；并行读取文件时用专门的 multi_tool_use.parallel 协议，比让模型自己拼 shell 并发更符合 harness 的可观察性和权限边界。

工具输出同样是 ACI 的一部分。长输出如果直接截断尾部，模型可能看不到测试最终失败原因；如果只保留尾部，又会丢掉命令启动上下文。Codex 指南建议保留开头和结尾，中间用明确截断标记替代，本质上是在为模型设计一个更可读的“工具结果 UI”。

Anthropic 的工具设计建议也强调这一点：工具响应应返回高信号上下文，而不是把内部数据结构原样倾倒给模型。自然语言名称、可解释字段和任务相关摘要通常比随机 UUID、底层 MIME 字段或全量列表更有用；需要技术 ID 支撑后续调用时，可以通过 concise / detailed 这类响应格式参数让 Agent 按需切换信息量。

ACI vs. HCI

维度	HCI	ACI
用户	人类	AI Agent
“UI”	界面、控件、反馈	工具定义、参数、文档
设计原则	可见性、反馈、防错	可见性（文档清晰）、反馈（工具结果明确）、防错（Poka-Yoke）
测试方式	用户测试、可用性研究	多示例运行、观察模型错误、迭代工具定义

在 Harness Engineering 中的位置

ACI 是 Harness Engineering（驾驭工程）的重要子领域：Harness 决定 Agent 在什么环境里运行、有哪些权限；ACI 决定 Agent 能用什么工具、用得好不好。

Model Context Protocol（模型上下文协议）提供了 ACI 的标准化实现层：工具定义、参数 Schema、描述文档都通过 MCP 标准暴露给模型。

Function Calling（函数调用）是 ACI 在模型 API 层的典型落点：函数名、description、JSON Schema、枚举、必填字段和 strict 设置共同构成模型可见的工具界面。OpenAI 的函数定义建议也与 ACI 一致：函数要清晰、直观，参数结构应让无效状态尽量不可表达，并避免让模型填写应用代码已经知道的参数。

ACI 也影响 Agent Guardrails（Agent 护栏）的负担。一个工具如果名称含糊、参数自由度过高、读写动作混在一起，护栏就只能在事后拦截更多误用；一个好的工具接口会把常见错误前移到 schema、枚举、权限和默认值里。

Computer-Using Agent把 ACI 问题推到更接近 HCI 的一端：Agent 不再只看函数 schema，而是读取屏幕、点击按钮、输入文本。此时“接口”既包括开发者暴露给模型的工具说明，也包括网页或桌面 UI 本身是否稳定、可观察、可回滚。