Ai Agent概念扫盲：多 Agent、Handoff、LSP 与 Computer Use

返回总览 · 上一篇 RAG。

一个 Agent 修代码，另一个检查是否破坏旧功能，看起来像两个人配合。

但它们是否看到相同资料、是否共享目录、谁最后负责合并结果，都需要程序设计。多 Agent 不会因为数量增加就自动形成团队。

这一篇把协作和观察环境放在一起讲，它们共同影响任务怎样从「安排了」走向「真的完成」。

Multi-agent 和 Subagent

Multi-agent 是多个 Agent 协作的系统。Subagent 是被委派子任务的 Agent。

子 Agent 可能拿到自己的目标、上下文和工具，也可能与主 Agent 共享部分环境。它可以使用同一个模型服务，独立 Agent 不等于独立模型或独立进程。

例如主 Agent 把任务拆成「修复」「检查兼容性」「验证回归」。每个子任务应有明确的范围、输入和交付标准。否则几名 Agent 都在读同一份代码、改同一个文件，成本和冲突就会增加。

Agent-as-a-Tool 把另一个 Agent 当成可调用能力。主 Agent 发出请求，收到结果，再决定下一步。

Handoff 把控制权移交给另一个 Agent，例如通用客服把后续退款处理交给退款 Agent。用户接下来主要与接手方交互，具体形式依实现定义。

「让审查 Agent 返回报告」和「让退款 Agent 接管后续对话」是两种交互语义。工具调用返回之后，主 Agent 通常仍保留控制；交接需要明确谁继续负责。

协作模式可参考 LangChain 的多 Agent 文档。这些是设计模式，不是各家同名功能完全一致的保证。

Orchestration，编排，安排任务依赖、调度、信息传递和汇总。

DAG 不包含环，State Graph 可以包含。把任务画成图，只说明依赖被表达出来，持久化和失败恢复仍需要额外实现。

相对独立的子任务更容易并行。比如一个检查登录逻辑，一个检查文档，两者修改范围不同，最终可以一起汇总。

先读代码才能确定修改点，先修改才能验证，这些步骤有依赖，不能直接同时推进。

交给子 Agent 的输入应保留目标、约束、上下文入口和交付标准。主 Agent 汇总时，还要处理结果冲突，不能把几份报告拼起来就默认成立。

共享工作区时，需要明确文件责任范围。隔离工作区时，也需要合并和重新验证集成结果。各自通过测试，不保证合在一起仍通过。

多 Agent 的收益可能是不同资料范围、独立审查和并行时间；代价包括重复上下文、交接损失、额外调用、取消传播和协调。相似模型看到相似资料时，也可能给出相同错误，投票数量不能自动变成事实证据。

Text Search 查字符串和关键词，适合错误码、配置名或特定文案。LSP 提供定义、引用、类型和诊断等语言服务。

例如 createOrder 在两个模块里同名，文本搜索都能找出来；语言服务能帮助确定某处引用属于哪一个定义。LSP 能力依语言服务器而定，调用成功也要检查结果是否覆盖当前文件版本。

AST，Abstract Syntax Tree，抽象语法树，表达代码的语法结构，适合一些结构化分析和变换。它与简单字符串匹配不同，但具体工具是否理解类型、能否安全重构，要继续看实现。

Diff 表示两个版本的差异；Patch 描述要应用的变更；String Replacement 匹配旧文本并替换；Full Rewrite 重写整个文件。

字符串替换直观，但依赖准确匹配；Patch 适合表达局部差异，但需要足够上下文定位；AST 修改适合部分结构变换；整文件重写容易表达完整结果，但改动范围更大。

选择编辑方式之后，还要读回结果。成功返回说明编辑器做完了某次操作，不说明它命中了正确业务位置，也不说明项目仍能运行。

已有的 Kimi Code 与 Coding Agent 的 Edit 设计比较了具体实现。版本结论以那篇记录的源码范围为准。

ACI，Agent-Computer Interface，是 Agent 与计算机交互的接口设计。

同样是搜索工具，返回十万行混杂文本，和返回带文件路径、行号、分页入口的结果，对后续判断的帮助不同。

接口还需要说明文件是否截断、错误发生在哪里、修改失败如何恢复、怎样确认操作生效。SWE-agent 原始论文把这类接口设计作为自动软件工程的重要部分。

Computer Use 让系统通过工具观察和操作电脑。浏览器操作也可以使用类似的观察、行动和反馈链。