Agents are not tools 关于Agent as tool及A2A两种模式的总结

工具负责执行一个边界明确的动作；Agent 负责在边界尚不明确时，与其他参与者持续协作解决问题。

Agent和tool的区别

Agent是有状态，tool是无状态的。同时最大的区别是Agent应该具有与环境交互和探索能力，并且整个过程应该是自然连续的，也就是说即使Agent需要人类的介入，而等待人回复的过程也应该作为Agent的一个完整过程的某个中间环节；而tool是更像是一次请求响应，有明确的入参和出参，并且对于tool外界来说没有中间态。

维度	Tool	Agent
角色	动作执行者	问题解决者、协作者
输入输出	有明确 schema，范围受限	可以是开放式、逐步形成的
控制流	调用 → 执行 → 成功或失败	可能追问、暂停、协商、恢复或改变方向
任务状态	工作中、完成、失败	还可能等待信息、等待人类操作、部分完成
再次调用	通常开始一次新操作	通常需要继续原来的上下文
自主性	按参数执行	可以判断当前条件并决定下一步

对于区分Agent和tool的核心依据

这个调用的语义究竟是执行一次动作，还是开启并持续推进一个问题解决过程？

Agent ↔ Agent：开放、多轮、可中断、可恢复
Agent → Tool：结构化、受约束、结果明确

Agent可以作为tool的情况

如果某个 Agent 被严格限制为：

• 接受一次请求；
• 不追问；
• 不暂停等待；
• 最终只返回完成结果或错误；
  那么它可以被当作 Tool 使用。一般来说如果Agent被设计成一个稳定且不需要外界再次引导的workflow，通常是可以作为tool的。

Agent to Agent： A2A

当被调用对象不再是“执行指令的函数”，而是“共同解决问题的自主参与者”时，A2A 为这种关系提供能力发现、持续对话、任务状态、异步执行、结果交付和安全互操作的统一协议。

Tool 模型的不足	A2A 提供的机制	实际作用
只能返回结果或错误	TaskStatus	表达工作中、等待输入、等待认证、完成、拒绝、失败等状态
单次调用，无状态	taskId、contextId	后续消息可以继续原任务和相关上下文
输入参数必须预先确定	Message	Agent 可以追问、澄清、协商、接收目标变更
默认短时同步	查询、订阅、流式、推送通知	支持长时间运行和断开连接后的继续处理
输出只有一次返回值	Artifact	独立管理文档、图片、结构化数据等阶段性或最终交付物
Agent 地址和能力需要写死	AgentCard	声明身份、能力、技能、端点、协议和认证要求
每个 Agent 都要定制适配	标准数据模型和操作	降低跨框架、跨语言、跨组织集成成本
可能需要暴露内部工具	不透明执行	调用方只知道能力和结果，无须知道远程 Agent 的模型、记忆和工具

通过A2A，就能让多Agent之间传递中间状态，通过类似：

Task: hotel-task-123
Status: input-required
Message: 请补充每晚预算，以及希望靠近哪个会议地点。

实现 Agent 与 Agent之间的中间状态传递，保留Agent的自我探索与解决问题的能力。

---

参考文献：

https://a2acn.com/docs/introduction/
https://discuss.google.dev/t/agents-are-not-tools/192812