Agent 架构为什么要把“大脑”和“手”拆开

如果你在做 AI agent，最容易犯的一个架构错误，就是让同一个软件既负责“理解目标、规划步骤、和人沟通”，又负责“稳定点击、执行命令、读写文件、反复重试”。更稳的做法，是把会思考的助理和会干活的手拆成两层：上层负责判断，下层负责执行。这也是 OmniGoAI 的 GoWork 在长期实战里逐步收敛出来的结构。

简化地说：大脑负责“做什么”，手负责“怎么稳稳做成”。当两者分离后，系统更容易解释、恢复、审计，也更容易把一套执行能力复用到不同模型和不同聊天入口里。

什么叫“大脑”和“手”

这里的“大脑”不是指某个模型名字，而是指那层面向任务和上下文的能力：

1. 理解用户真正想要的结果；
2. 决定下一步该读什么、查什么、改什么；
3. 在不确定时向用户追问；
4. 在多步骤任务里维护计划与状态；
5. 把最终结果用人能理解的话汇报出来。

而“手”指的是可重复、可验证、偏确定性的动作层，比如：

1. 调 shell 命令；
2. 读写文件；
3. 操作桌面应用；
4. 访问本地工具或受控 API；
5. 按固定协议返回成功、失败和中间状态。

如果把这两类职责硬塞进同一个黑盒里，问题通常不是“能不能跑一次”，而是“能不能连续一百次都跑得可解释、可恢复”。

为什么一个软件同时做两件事，往往更脆

单体 agent 看起来最省事：一个模型接到请求后，自己思考、自己执行、自己汇报。早期 Demo 往往也是这么做的。

但一旦进入真实环境，这种设计会同时遇到三类问题。

1. 推理与执行的失败模式完全不同

推理层常见的问题是：理解偏差、计划失真、上下文遗忘、过度自信。执行层常见的问题则是：命令参数错、窗口没焦点、文件路径不对、平台登录态失效、网络抖动。

这两类问题的修复方法不一样。

• 推理错了，要补上下文、改计划、换提问方式；
• 执行错了，要重试、换探针、换路径、补验证。

如果两者搅在一起，系统最后只会给你一个模糊结论：“失败了，但说不清是想错了还是做错了。”

2. 黑盒执行很难审计

团队真的把 agent 用起来后，迟早会问三个问题：

• 它刚才到底改了什么？
• 它依据什么做出这个判断？
• 失败前最后一个真实动作是什么？

如果大脑和手没有边界，很多现场就只剩一句“模型判断如此”。这对排错、合规、复盘都不够。

把执行层独立出来后，每一个动作都能变成结构化事件：读了哪个文件、跑了哪条命令、返回了什么错误、哪一步验证通过了。这类记录既能帮助人追责，也能帮助 agent 下一轮从上次进度继续，而不是整段重来。

3. 入口变多后，单体架构会越来越乱

今天的 agent 往往不只活在一个窗口里。它可能同时出现在网页、钉钉、飞书、Telegram、定时任务、后台巡检里。

如果每个入口都自带一套“思考 + 执行”闭环，你很快会得到多套彼此漂移的逻辑：

• A 入口能查任务状态，B 入口不能；
• 网页版会先确认，IM 版直接执行；
• 定时任务能继续上次进度，聊天入口却完全不知道历史。

把“大脑”统一成会话与任务层，把“手”统一成执行层，入口才能只是入口，而不是另一套产品。

拆分后的架构，稳定性提升在哪里

真正的收益不只是“代码更优雅”，而是运行层面更可控。

上层可以专心做判断

当执行动作被封装成明确的工具和事件后，上层助理只需要关心：

• 当前证据是否足够；
• 下一步最值得做什么；
• 是否需要用户补信息；
• 是否已经达到一个自然完成点。

它不必同时兼顾每个桌面坐标、命令转义细节或平台按钮状态。这样做的直接好处，是推理层更像一个真正的 supervisor，而不是一边思考一边兼任脆弱脚本。

下层可以专心做确定性动作

执行层一旦独立，就能围绕“可靠完成动作”持续优化，比如：

• 启动长任务时统一走后台并轮询输出；
• 对桌面资源做串行排队，避免多个任务抢同一套鼠标键盘；
• 对文件、命令、网页、桌面截图建立统一验证方式；
• 把错误分成可重试、需登录、需人工确认、永久失败等类型。

这类能力本质上和“会不会写一段漂亮解释”没关系，却直接决定 agent 能不能真的帮人把事情做完。

为什么这种分工更适合聊天式 AI 助理

聊天式产品天然会遇到“上下文很多、动作很多、用户随时打断”的问题。

这时如果没有大脑/手的分层，常见结果是：

1. 用户一句“刚才那个继续”，系统不知道该续哪个任务；
2. 用户一句“停”，系统停不掉真正执行中的那条链路；
3. 一个任务正在操作桌面，另一个任务又抢着点鼠标；
4. 定时任务跑起来时，只会重新做一遍，而不会接着历史状态收尾。

GoWork 这类常驻助理之所以要把任务、会话、运行历史、待确认动作分层保存，就是因为“能回消息”不等于“能持续执行”。如果你关心的是长期协作，而不是一次性问答，执行边界一定要清楚。

你也可以参考这两篇相关内容：

• https://omnigoai.com/zh/blog/gowork-dingtalk-bot-vs-resident-assistant/
• https://omnigoai.com/zh/blog/gowork-task-status-in-chat/

什么时候不需要拆分

并不是所有 AI 工具都必须上这种结构。

如果你的产品只做下面这类场景：

• 单轮问答；
• 没有外部副作用；
• 不读写本地文件；
• 不操作桌面或第三方软件；
• 失败后直接让用户重新问一次即可；

那一个轻量单体 agent 完全够用。

问题在于，一旦你开始承诺“我来替你做事”，系统就进入了另一种工程范畴。此时真正难的已经不是生成文字，而是：怎么在不失控的情况下持续执行。

设计执行层时，最容易忽略的 4 个点

1. 探针的结论范围要小心

很多错误不是“没装”“不存在”，而是探针本身覆盖不够。

例如 where chrome 为空，只能说明 PATH 里没有 chrome.exe，不能证明机器没装 Chrome。执行层必须知道每种探针能证明什么，不能把弱证据说成强结论。

2. 长动作不能假装成功

安装、构建、启动本地服务这类动作，常常超过一分钟，前台超时被杀并不等于“服务已经起来了”。执行层必须在后台运行长任务，再用进程、窗口或产物文件做真实验证。

3. 共享资源必须串联

桌面自动化尤其明显：同一时间只有一套鼠标键盘和前台窗口。谁在用、谁排队、谁等待、谁取消，都要由执行层统一协调，而不是让上层模型临场猜。

4. 失败后要保留可续跑状态

好的执行系统不会把一次失败当成整段任务作废。它会记住：

• 已完成了哪些步骤；
• 哪些结果已经验证；
• 下一轮该从哪里继续；
• 哪些失败需要用户介入。

这决定了用户说“继续”时，系统是在真继续，还是换个说法重来一次。

对团队来说，拆分带来的不是“更复杂”，而是边界更清楚

很多团队一开始抗拒分层，是觉得多了一层调度、多了一层协议，看上去更复杂。

但从维护角度看，边界清楚比表面简单更重要：

• 产品层知道自己承诺的是什么；
• 执行层知道自己必须验证什么；
• 失败时人能迅速定位责任面；
• 未来要换模型、换入口、换某个工具时，不用整套重写。

尤其当你想把同一个助理接到多个聊天渠道、多个定时任务和多个执行环境里时，“大脑/手分离”几乎不是风格偏好，而是规模化的前提。

常见问题

大脑和手拆开，会不会让系统更慢？

有可能多一层调度开销，但通常换来的是更少的误操作和更高的恢复成功率。对真实任务来说，少重跑一次往往比省下几百毫秒更重要。

执行层一定要完全无智能吗？

不一定。执行层可以有局部策略，比如自动重试、路径回退、资源排队，但它最好不要自己改变任务目标。目标解释权应留在上层。

一个模型同时担任两层角色可以吗？

可以，但架构边界仍然要存在。即使底层和上层都由同一模型驱动，职责、状态、验证和日志也最好分开，否则后期会越来越难排错。

对用户最直接的收益是什么？

最直接的收益是三件事：结果更稳、失败更容易解释、任务更容易续跑。用户真正感知到的不是“架构优雅”，而是“它没那么容易乱来”。

如果你正在把 AI 从“会聊天”推进到“会执行”，一个很实用的原则是：让助理负责理解和决策，让工具层负责稳定地把动作做完。如果你想把这种分层真正落到聊天协作、任务状态、定时执行和跨渠道助理里，可以从 GoWork 开始：

https://omnigoai.com/zh/download/gowork/