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

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 请后台留言哦。

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

01 | 照着行业闭环结构搭了一遍

我发现这五个环节缺一不可

AI Native 到底怎么落地？

先看看 Manus 类 AI Agent 都是怎么干活的，

流程很清晰：

用户一句话 → AI 识别需求 → 决定要干嘛 → 调用工具 → 拿到结果 → 判断后续 → 重复直到完成。

你会发现，这里面其实天然分成了五段：理解、决策、执行、反馈、学习（现网大部分产品缺少学习环节）。

目前，几乎所有主流 Agent（Manus、Auto-GPT、扣子空间、天工）都在跑这个结构，只是机制和策略不同。

我在做 Alice 的时候，基本也是按这个结构来复刻的。

但实践下来才发现——这些看起来顺理成章的五段，但如果希望每一段跑通，都比想象中麻烦得多，并且，一旦少了一环，系统就会变得很别扭。

下面我就按这五个阶段说说我怎么做的、踩了哪些坑、为什么最后保留了这个设计。

感知与理解：让 AI 知道“它能干嘛”这件事，比理解用户更难

最早我以为模型只要听懂用户的话就行，结果发现 AI 最大的问题不是“理解用户”，而是“不了解自己能做什么”。

因为，如果你不把工具的信息喂给它，它压根不知道自己该不该干、能不能干、怎么干。

所以我做了个基础机制：每次请求前，系统会构建一段工具调用上下文（tool schema），把当前注册的工具及其参数说明、用途、调用格式全写进去，注入到模型的 prompt 里。

这套逻辑在 core.py 的 _process_messages_with_tools() 里。所有工具 schema 则通过 ToolRegistry 统一注册，自动生成。

为了适配不同模型（Claude、通义千问、Qwen），我在 models.py 做了多模型适配层。通义千问有自己的思考链输出字段，我也单独支持了解析。

说白了，就是：让模型知道它自己现在能干什么。

不然你让它「总结这份 Excel」，它可能会说：“我建议你可以试着找一个支持表格的工具来分析，比如说 XXXX。”

决策与规划：模型不是不会规划，而是系统不支持它多轮干活

规划是一个反复判断 → 反复调用工具的过程。

主流 Agent 的做法也差不多，比如 Auto-GPT 和 Cursor 都是典型的 ReAct 模式：每一轮“思考 → 调用工具 → 拿结果 → 继续思考”，就这样循环。

所以我也这么做了：在 core.py 的 chat_stream 方法中，写了一个最多支持 30 轮的交互主循环。

每一轮都包括：

• 构建历史消息

• 调用模型判断下一步

• 如果输出了工具调用 → 执行

• 把结果写入上下文 → 进入下一轮

这事听起来简单，做起来细节巨多，比如：

• 每次输出格式可能乱，tool_call 的 XML 结构不一致，要容错解析（xml_parser.py）

• 多个 tool_call 会同时出现，要强制只保留一个（我加了个限制）

• 工具执行后，要把结果格式化回来再写入下一轮上下文（标准化的 ToolResult）

总之就是照着 Auto-GPT 那种“边思考边干活”的结构，自己补齐所有胶水层。

执行与调用：统一调用接口之后，问题才刚刚开始

Manus 类 Agent 有一个共同点：工具能力是核心，调用必须可控。

为了减少开发代价，我使用了装饰器方案，

在 tool_manager.py 写了一个统一的工具注册与执行框架：

• 所有工具都通过 @register_tool 装饰器注册（声明式）

• 支持同步函数和异步函数

• 自动完成参数校验、类型转换

• 调用后统一生成 ToolResult

但执行层问题远不止这些。

最早我以为“能跑起来”就行了，但随着工具的越做越多，带来最显著的问题是：

1、一些工具需要用户二次确认，否则极其危险：比如对文件的删改，调用 系统的 Command；

2、大模型的遵循能力不完全稳定，经常性的会出现参数类型错填，参数不完整的情况；

3、目前已有上百个工具，如果所有工具都放到 System Prompt 中，不但会带来不必要的开销，

（比如：回答用户简单的问题，根本不需要用工具的场景，那么浪费了工具的 token ）

而且影响模型输出效果，因为工具的描述本质上也是提示词，长上下文会影响模型生成内容的长度与质量。

最后，我发现必须加上：

• 风险控制：删除文件这类工具必须二次确认，否则后果很难收拾我在 user_confirmation.py 做了等级机制

• 参数校验机制：模型可能漏传参数或者类型不匹配，导致直接报错，需要兜底处理

• 工具隔离机制：不能每次都加载所有工具模块，要根据任务按需激活（tool_module_manager.py）

所以这一步的重点是：不仅仅让工具能被调用，而是让系统知道如何安全、正确、稳定地调用。

反馈与评估：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 架构：为什么工具分层如此重要？

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

欢迎关注。

文章来自于微信公众号“洛小山”，作者是“洛小山”。