想做 Agent,先让它比较两份文档

想动手做一个 Agent，打开教程，先遇到一张架构图：记忆、规划、工具、知识库、专家协作。每一项似乎都重要，却很难知道第一步该写什么。

可以先把目标缩到一件事：给它两份文档，让它读出变化，保留共同条件，再交出一份能重新打开的报告。 这件事足够小，也已经包含了 Agent 最重要的工作方式。

下面用一个合成教学案例讲清楚。先理解动作怎样接起来，再看可以自己运行的公开示例。

教学示意：读取资料后选择下一步，最终交出结果

从一个你已经会做的任务开始

假设有人交给你 A、B 两版产品指南，问：免费版的导出格式有什么变化？两版有什么共同限制？

A 版写着：支持 CSV 导出，需要联网。B 版写着：支持 CSV 和 Markdown 导出，也需要联网。

你会先读两份材料，再给出判断：B 版新增 Markdown 导出，两版都要求联网。这段结论不复杂，但它依赖真正读到两份资料，不能靠产品名称猜出来。

Agent 也要完成这些动作。区别在于，开发者可以把一部分推进任务的选择交给模型：先读什么，是否还缺材料，什么时候开始回答。

工具结果，要回到下一轮判断里

第一轮，模型选择读取 A 版。工具返回正文，运行程序把它加入下一轮输入。

第二轮，模型知道自己只看过 A，还需要 B，于是继续读取。拿到 B 以后，才有条件比较。

第三轮，模型整理变化和共同限制，形成回答。如果 B 版写着“导出要求见附录”，它还可以决定继续读附录，而不是按预先写死的页数结束。

这个过程就是 Agent 循环：模型选择动作，工具实际执行，结果交回模型，再决定下一步。 几轮工作可以发生在同一次用户请求里，不需要用户每一步都催。

运行程序负责把循环接起来，并落实工具范围和执行上限。模型说“我要读文件”，不代表任意文件都能读；模型说“已经保存”，也不能替代保存工具的真实结果。

下面这张图只保留三个角色。先弄清谁选动作、谁执行、谁把结果接回去，就能看懂最小主链。

模型选择下一步，运行程序组织循环，工具执行动作

普通脚本已经能做，为什么还用 Agent？

如果任务永远都是“读 A、读 B、按固定规则比较”，直接写脚本很合理。比较这一步即使用了大模型，整个流程仍然可以由代码预先安排。

Agent 更适合路径会随着材料改变的任务。读到附录线索，需要继续追；发现版本不一致，需要核对；资料不足，需要缩小结论。下一步是什么，要等这一轮结果出来才知道。

Anthropic 在《Building effective agents》中也用“由预定路径组织工作”与“由模型动态选择过程和工具”区分工作流和 Agent。实际产品可以把两者结合起来，不必为一个名称重写所有稳定步骤。

判断是否值得用 Agent，可以先问：这项任务经常需要根据新信息改变下一步吗？ 如果没有，普通代码可能更省事。

跑一次小例子，观察真实产物

Open ETF Agent 的公开 v0.15.0 版本提供了这份文档比较示例。按该版本说明，准备 Node.js 26.8.1–26.x 后，可以执行：

git clone https://github.com/hpoenixf/open-etf-agent.gitcd open-etf-agentgit checkout v0.15.0npm ci --ignore-scripts --no-audit --no-fundnpm run buildnpm run demo -- --case document-compare

这里有一个重要条件：默认示例用脚本模拟模型动作，但读取文档、执行工具和保存报告是真实步骤。 它让你不配置模型密钥也能观察过程，不用来证明真实模型已经能自主完成研究。本次改编没有重新运行该示例。

命令按版本设计会输出任务目录，其中的 report.md 是可以打开核对的产物。不要只看终端有没有“成功”，可以检查报告是否保留了“需要联网”这个共同条件，再回到两份指南核对。

第一个版本，先守住三个具体问题

两份材料只读到一份，助手应当说明已核实什么、还缺什么。它可以交出有限结果，不能把没读到的内容当作没有变化。

保存请求已经发出、回执却没回来，应先查询记录和产物。结果未知不能直接当成没发生，再执行一次。

报告说保存好了，退出以后还应能从读取入口拿到对应内容。重新生成一份相似文字，不能替代读回刚才保存的报告。

这些问题能把“模型会回答”和“程序能做完一项任务”接起来。它们也比第一天记住十个模块名字更有用。

先让两份文档走完读取、判断、保存、回读。资料多了，再处理上下文；需要跨次使用，再考虑记忆；确实有独立核对任务，再加入专家。每一项新增能力，都有一个看得见的理由。

相关资料与完整原文可点击文末「阅读原文」查看。