第一次看到模型自动调用搜索、数据库和终端时，很容易把 Agent 理解成“会使用工具的聊天机器人”。但把演示放进真实系统后，问题马上从提示词转向工程：权限如何限制，失败怎样恢复，状态放在哪里，每一步又由谁审计。

工具只是入口

一个工具至少需要清楚描述输入、输出、错误和副作用。读取天气与删除文件不应该拥有同一种确认策略；查询数据库与执行设备指令也不应该共享同一层权限。

我更愿意把 Agent 看成一个受约束的状态机：模型负责提出下一步，运行时负责验证参数、检查授权、执行动作并记录结果。模型可以有判断力，但不能同时成为自己的门禁系统。

MCP 与 A2A 解决的不是同一个问题

MCP（Model Context Protocol）把模型应用连接到工具与上下文，重点是客户端如何发现并调用能力。A2A（Agent2Agent Protocol）关注不同 Agent 之间如何描述能力、委派任务和交换结果。

可以把它们粗略地理解为两条边：

1
2
Agent -> 工具/数据：MCP
Agent -> Agent：A2A

协议带来的价值不是让系统名字更先进，而是减少每接一个数据源就写一套私有适配器的成本。与此同时，协议不会自动解决安全问题。可调用不等于可授权，能返回结果也不等于结果可信。

记忆应该分层

对话全文直接塞回上下文，是最简单也最昂贵的记忆。实际系统可以分成短期状态、用户偏好、任务事实和可检索知识。每一层都有不同的保存周期与删除规则。

例如“当前实验的磁场值”属于任务状态，“用户习惯使用 SI 单位”属于偏好，而文章内容属于知识库。混在一起后，模型既难找到真正重要的信息，也容易把过时状态当成事实。

没有轨迹，就没有评测

Agent 的最终回答正确，不代表过程可靠。评测还要覆盖工具选择、参数正确性、无效重试次数、权限越界和中间事实。最好保存完整但脱敏的执行轨迹，让失败可以复现。

我认为 Agent 工程真正的分水岭，是系统能否回答三个问题：它为什么执行这一步，失败后如何恢复，出了问题由谁负责。只有这三件事清楚了，自动化才不只是一次漂亮的演示。

参考资料：