从零手写 Agent（七）：和商用 Agent 还差什么——个人调研 Agent 的边界

前面几篇已经把一个能实际运行的 Agent 搭起来了：

作为一个个人调研 Agent，这套东西已经能完成基本任务。

但如果拿它和成熟的商用 Agent 放在一起比较，差距还是比较明显的。

现在的 Agent 主要依赖：

商用 Agent 往往还需要处理：

所以第一层差距不是模型，而是数据获取和数据处理能力。

现在的 _agent_loop 更接近：

思考
→ 调 Tool
→ 看结果
→ 继续思考
→ 调 Tool
→ ...

对于“搜索几个资料，然后生成报告”这种任务已经够用。

但任务变长以后，就会需要更明确的：

Plan
→ Execute
→ Observe
→ Re-plan
→ Verify
→ Deliver

例如一个复杂调研任务，可能需要拆成多个子任务，并记录哪些已经完成、哪些失败、哪些需要重新执行。

当前版本没有专门的 Planner，也没有持久化的任务状态。

现在虽然已经记录了 sources，但还没有真正建立完整的结果验证机制。

例如：

搜索成功
≠
找到正确资料

找到资料
≠
引用正确

生成报告
≠
任务完成

当前版本最多可以知道 Agent 调用了哪些 Tool、拿到了哪些来源。

如果要进一步提高可靠性，还需要：

也就是说，需要从“能跑”进一步走向“可验证”。

当前版本可以接本地 7B 模型，也可以切换到 OpenAI 兼容的云端模型。

模型能力会直接影响：

特别是任务变复杂以后，小模型更容易出现：

该调用 Tool 的时候不调用

或者：

已经拿到结果，但不知道下一步应该做什么

所以 Agent 能力并不完全由 Loop 决定，模型本身也是整个系统的一部分。

当前版本是本地个人项目，因此很多生产环境必须考虑的问题都没有做。

例如：

尤其是加入 fetch_url、Shell、代码执行这类 Tool 后，安全边界会迅速变复杂。

本地 Demo 可以直接访问 URL。

真正的线上 Agent 则不能简单地相信模型给出的 URL。

现在的 Agent 基本属于：

一次请求
→ 一次执行
→ 一次结果

如果任务运行几十分钟甚至几个小时，就需要考虑：

这时候 Agent 就不再只是一个函数调用，而更接近一个有状态的任务系统。

对照下来

把目前这个 Agent 和商用 Agent 放在一起，差距大致可以归纳成：