从会对话到会干活，AIAgent如何实现动作闭环？

Hi，周末好！

我是洛小山，与你深入聊聊 AI 工程化。

这是我关于「AI Native 系列」的第二篇文章，主题是：行动闭环。

在上一篇里，我讲了什么样的产品才算得上真正的 AI Native，分享了我对 MCP 协议、AI 架构原生性和任务闭环的理解。

而这篇，我们要从“干活”这件事本身出发，聊聊一个更具体的问题：

AI 要从“会聊天”变成“能干活”，到底还差几步？

在这篇文章里，我会用我开发的 Agent 框架，

先讲相关技术实现

再横向对比目前主流的 AI Agent 架构，

最后分享我对行动闭环的三点判断。

希望这篇文章能为你提供一个不那么理论化，不那么泛泛而谈的视角，理解 Agent 调度的本质。看它是否有能力自己接住任务、干完任务、持续变好。

如果你对技术实现不感兴趣，可以快速略过到第二章。

如果有疑问，欢迎在评论区提出。

Github 地址

为规避恶意爬库，请后台私信 「框架」 获取。

使用方式：

Clone 下来之后，用 Cursor 打开，

阅读 README_FOR_CURSOR.md或者

填好 Config.json，接着运行run_web.py

最后访问http://127.0.0.1:8000/和 AI 对话。

如果遇到 Bug 请后台留言哦。

项目没有加鉴权逻辑，请务必小心，避免发到公网。

反馈与评估：AI 干完活后怎么知道“活干得怎么样”？

很多闭环系统在这一步处理会比较简单：工具调用完就只返回返回结果，但经过实践，除了返回值以外，最好再返回运行时的一些状态，辅助大模型进行判断。

并且，返回值最好也遵循工具调用的格式，比如在每次工具调用后，都生成一个结构化的 ToolResult，然后把它格式化写进上下文，送入下一轮对话。

模型会在新一轮看到这个结构，再决定怎么处理。

另外我还做了执行记录持久化，所有调用记录都会写入 database.py 的 SQLite，用于后续调试与模型行为分析。

闭环的关键在这一步：让模型“看得见自己做过什么”，否则它只是每轮都在盲试。

请见下图，当大模型执行错误的时候， 需要明确返回错误的具体原因，让大模型知道下一步应该怎么办。

在错误中返回正确参数列表带来的显著好处，就是能省一次调用带来的 Token 开销。

因为，如果在返回值中没有带上正确内容， 大模型将额外调用一次工具，这种调用本可通过更丰富的返回值避免。

学习与优化：不是每个产品都做了，但我觉得这一步不能省略

在调研阶段我发现，大多数产品的行动逻辑，其实只停在前四步——理解、规划、执行、拿到结果。

工具调完，给你输出一个 markdown 或 HTML 格式的总结，这一轮任务就算完成。

如果你换个场景、换个表达方式再问一次，它又从头来过。

这种行为当然可以跑得起来，但它并不“闭环”。

因为 AI 完成的是一个段落，而不是一条路径。

我觉得：“学习”这一步，其实才是真正让系统越用越顺、越跑越准的根源。

不是指模型能力变强，而是让系统记住：这个用户喜欢保留哪些默认选项、哪些工具默认是可调用的、上一次类似任务是怎么做的。

所以我补上了这块：

在工具层加了结构化的记忆模块（MemoryManager）

在数据库中记录所有对话与工具调用历史

在用户确认机制中保留“上一次的选择”，自动适配是否再次弹出确认

严格来说，学习与优化这个动作，目的是为了让系统少打扰一次用户，少走一条重复的路。

从用户体验角度看，它能减少对用户的打扰；

从商业化角度看，它直接节省 Token ；

从系统角度来看，它带来推理效率的提升。

对我来说，这才是“行动闭环”真正闭合的标：系统在过程中形成了路径偏好和行为积累，帮助下一次可以更稳、更准地完成类似任务。

上面这五个阶段，是我在构建闭环系统的过程中慢慢拼接上来的。虽然它们未必都被主流 Agent 架构所强调，但确实是在我实际做 Alice 的过程中的体会。

说实话，后面这一部分我本来是想写得更技术一点，比如模块拆解、类结构设计、调用接口封装…

我有点担心内容太重、太细，不一定适合大家的阅读习惯。

所以这里我想先征求下意见：你是否会对AI 闭环系统背后的工程细节感兴趣？

如果想看，后面我会单独写一篇拆解文章来讲清楚：每个模块是怎么串起来的。

还有件小事，最近有家出版社联系我，想让我写一本关于 AI Agent / Native 工程化技巧 或 TPM 能力提升路径的书。

你觉得这个方向有意思吗？帮我做个选择？

02 | Manus 类 AI Agent 对比分析：什么才是真正的闭环智能体？

在把 Alice 工具调用的闭环结构跑通之后，我重新回顾市面上的几款主流 AI Agent 产品：Manus、Auto-GPT、Flowith NEO、扣子空间、OpenManus 等。

它们的风格、定位、策略各不相同，但都有一个共同目标：让 AI 能自主完成复杂任务，成为真正能干活的智能体。

所以我尝试从“行动闭环”这个角度来重新看它们：这些产品到底有没有形成闭环？

这个闭环是结构性的，还是只是表面的流程演示？

不同 Agent 在闭环策略上的路径差异

从架构角度来看，现在的 Agent 系统大致分为五种典型策略路径：

第一类是 ReAct 模式，也是 Auto-GPT 的经典做法。模型每次生成一个“思考+行动”，执行工具后再观察结果，进入下一轮。这种方式的优点是灵活，能边做边调，但问题也很明显：缺乏全局计划，一旦上下文跟不上，容易原地兜圈。

第二类是 Plan-and-Execute，比如部分 Manus 子流程，或者 OpenManus 的任务预规划流程。AI 会先整体拆解任务，再逐步执行每一步。

这种结构更像项目经理，有助于任务收敛，但缺少重新拆解动作，一旦初始规划错了，后面就很难修正。

第三类是 链式 Agent 协作（Agent Chain），比如 BabyAGI 的设计。它由多个子Agent轮流接力，一个负责生成任务清单，一个执行，一个调整优先级。

这种架构适合任务未知、目标不明确的探索型任务，但因为会重新调整队列的优先级，收敛速度慢，Token 容易膨胀。

第四类是 多 Agent 分工结构，典型代表是 天工 和 Convergence Proxy。在它们的体系中，一个高层 Agent 负责拆任务、派单，多个执行 Agent 各自处理子任务。好处是专业化，效率高，但系统调度的成本也是最高的。

最后是 记忆驱动型（Memory-Driven）Agent，比如 Flowith NEO / Cursor 。它强调超长上下文与持久记忆，通过上下文窗口扩展和外部知识接入，让 Agent 可以跑非常长的任务、处理超大信息流，甚至记住跨会话的偏好和知识。

这也是我最推荐的结构。

虽然这些结构各有优势，也各有取舍。

但只要让模型看到上一次的结果，AI 的行为就会开始出现类似人类的路径意识：它会根据上下文该不该重试、需不需要问确认、这个文件是不是上次读过的。

这就是很多 Agent 系统能生效的关键。

闭环不是有规划，而是能走完一段路

很多产品都在强调自己能规划、能执行，但我现在的判断是：

闭环的关键比拼的不是规划能力，而是系统有没有完成路径的能力。

路径能力意味着什么？

意味着你能连续执行、能看见结果、能判断偏差、能做出调整、还能记住这段过程。

如果没有结果感知，每一轮都像新的一轮**；

如果没有记忆能力，整个系统就只能永远从头试错。

我现在更看重的是三件事：

模型能不能知道上一步干了什么？

系统能不能基于结果做出判断？

用户的行为能不能变成偏好而不是重复动作？

这三件事能做到，才能算作真正的闭环。

四、我对行动闭环的三点判断

写完这个框架之后，我愈发觉得：

行动闭环这件事，表面看起来像流程调度，但本质上是架构设计。

从一个任务入口走进来，要让 AI 真正把事做完，不仅仅考模型的推理能力、prompt 设计，更是是靠系统结构设计，能不能具备健壮性，接得住大模型的每一步。

而这个结构能接得住的关键，最后我归结成三点判断。

判断一：AI 不缺能力，胶水层缺结构

很多人看到一个任务做不下来，会说“模型还不够聪明”、“理解能力不行”、“上下文长度不行”，但我的经验是：

模型的能力早就够用了，问题往往是结构不完整，信息断了、流程断了、记忆断了。

如果没有告诉它能用哪些工具，它当然不会调用。

如果没有上一次的结果，它当然不知道要不要继续。

毕竟，不记住它刚才做了什么，它只能反复试错。

所以闭环的核心不是模型能力堆叠，而是让模型拥有一个能走得通的工作结构。

判断二：闭环的核心是反馈机制

AI 能执行一个工具、不等于闭环成立了。

我一开始也以为只要工具调起来，AI 就能把任务做完。

但后来发现，真正让系统稳定运行下去的，除了工具以外，更是调完之后能不能知道调得对不对的结果。

如果没有统一反馈结构、没有结果注入机制、没有异常判断逻辑，那模型就只能边做边猜。

所以我后来开始更重视 ToolResult 的结构、每一轮消息上下文的组织、失败情况的可视化。

虽然这些不写在模型 System prompt 里，却直接决定了模型下一轮生成是否靠谱。

闭环真正的重心，在于结果能不能被模型看见、读懂，并基于它调整行为。

判断三：协作系统才是行动闭环的前提

我最早做这个项目时，目标只是让 AI 能把一个任务做完。

但现在回头看，闭环能力只是底层条件，真正有意义的是它为多模块协作奠定了结构基础。

一个能完成闭环的 Agent，才有可能：

支撑模块化任务链路（每步可拆、可插拔）；

接入异步任务执行（中间可以 pause、resume）；

承载专业化工具体系（高风险调用带确认、低风险自动运行）；

支持多 Agent 分工（上层决策 + 下层工具调度 + 持久状态传递）；

如果闭环都做不到，这些就只是功能拼盘，根本连不上。

而下一篇我想讨论的，就是这个结构延伸出来的下一层系统能力：工具分层架构设计。

为什么有的系统调 10 个工具还很稳，而有的系统调 3 个就混乱？

为什么要区分“核心工具”“上下文工具”“用户自定义模块”？

为什么我在 ai_chat_tools 里一定要强行加一层 module 激活系统？

这些问题，其实都跟“闭环之后怎么调协作”有关。

我们下一篇就接着说：

从代码看 AI Native 架构：为什么工具分层如此重要？

工具系统不是能调用就够了，它背后也有架构边界、有治理逻辑、有信任策略。从闭环的出口，走向系统协作的入口，我们继续往下拆。

欢迎关注。