106. 工具执行流程与多 Agent 边界

学习目标

这一节继续梳理工具调用的完整流程，并讨论多工具、多 Agent 和上下文长度带来的真实问题。

学完后，你应该能理解：

• 工具调用为什么要在稳定性和体验之间取舍；
• 多个工具能不能并发调用取决于业务场景；
• 查询代码时为什么要带行号；
• 按行更新为什么比整文件替换更适合 AI 编辑；
• 上下文窗口为什么会限制复杂 Agent；
• 多 Agent 修改同一代码库时为什么会出现冲突。

回复结束后执行工具

课程里采用的工具执行方式是：等模型回复结束后，再解析工具块并执行工具。

这种方式不是最快的。

更激进的做法是在模型流式输出过程中，一发现完整工具块就立刻执行。

但流式执行更容易出错，因为工具块可能夹在普通文本、推理内容或多个片段之间。

当前课程选择稳定优先：

• 模型完整回复；
• 系统解析所有工具块；
• 匹配工具；
• 执行工具；
• 把结果发回模型。

对刚入门的人来说，先把这条稳定链路跑通，比追求极致实时体验更重要。

多工具并发

模型有时会一次性返回多个工具调用。

这些工具能不能并发执行，没有固定答案。

如果工具只是读取信息，例如查询模块信息、读取代码、读取技能，通常可以并发。

如果工具会修改数据，例如执行 SQL、更新代码、保存配置，就要谨慎。

课程里强调要根据场景判断：

• 读操作可以更开放；
• 写操作要考虑顺序；
• 有依赖关系的工具不能乱并发；
• 容易冲突的工具要限制并发。

这和前端并发请求类似。不是所有 Promise.all 都安全。

查询代码为什么要带行号

AI 要编辑代码，第一步通常是读取代码。

课程里为读取前端代码的工具设计了 showLine、起始行、结束行等参数。

原因是后面要支持按行更新。

如果 AI 读取代码时看不到行号，它就会自己数行。

模型自己数行很容易数错，一旦行号错了，按行替换就会改错位置。

所以工具应该主动把行号提供给模型。

这不是为了人看得舒服，而是为了降低 AI 后续编辑代码的错误率。

按行更新代码

整文件替换看起来简单，但风险很高。

如果每次修改都替换整个文件，会带来几个问题：

• diff 变得很大；
• 容易误删无关内容；
• 模型容易重写不该动的代码；
• 审查修改成本变高。

按行更新更适合 AI 编辑。

AI 先读取带行号的代码，再指定要替换的起止行，最后只替换局部内容。

这和你在 IDE 里只改几行代码是同一个思路。

换行符细节

读取代码时还要处理不同系统的换行符。

macOS 和 Linux 常见换行是 \n。

Windows 常见换行是 \r\n。

如果工具没有处理好这些差异，模型看到的行号和实际替换的行号可能会不一致。

这种细节很小，但在 AI 自动编辑代码时会放大成真实错误。

上下文窗口限制

Agent 不是无限聪明。

当代码、技能、工具结果、历史对话都塞进上下文后，上下文会越来越长。

上下文太长会带来几个问题：

• 模型成本上升；
• 速度变慢；
• 容易忽略重要信息；
• 幻觉概率变高；
• 复杂任务更容易失败。

所以课程反复强调要通过工具按需读取，不要一次性把所有东西都塞给模型。

多 Agent 的冲突问题

课程还讨论了多 Agent。

多个 Agent 并行开发听起来很强，但问题也很多。

如果多个 Agent 修改同一个文件，就会产生冲突。

如果每个 Agent 修改不同模块，问题会少一些。

更复杂的策略是让每个 Agent 像程序员一样使用 Git：

• 拉取代码；
• 在自己的分支修改；
• 提交变更；
• 尝试合并；
• 冲突交给专门的 Agent 或人处理。

但合并冲突的 Agent 需要理解所有业务，否则它也可能合错。

阶段重点

这一节不是让你马上做一个多 Agent 平台。

重点是建立边界感：

工具调用要先求稳，多工具并发要看场景，AI 编辑代码要给足定位信息，多 Agent 协作一定会遇到上下文和冲突问题。

这些问题提前想清楚，后面做真正的 Agent 系统时才不会只停留在概念演示。