我一开始想拆 Agent，不是因为我想做一套很酷的 multi-agent 架构。

原因很简单：一个 Agent 不够用了。

不是能力不够，而是所有事情都挤在同一个窗口里。它在处理一条工作任务，我就不好继续问另一个问题；它在跑一个长任务，我就得等；我中途插一句别的事，前面那条任务的上下文又容易被冲掉。

时间久了，我发现真正卡住我的不是“缺一个更聪明的 Agent”，而是缺几条互不干扰的工作线。

一个万能 Agent，最大的问题是会堵

刚开始，一个万能 Agent 很好用。

写东西、查日志、看服务器、记事项、跑脚本、整理资料，什么都丢给它。入口统一，确实省心。

但问题也很快出现。

很多任务本来没有先后关系，却被迫排队：

先等它查完一个问题
再让它处理另一个问题
再插入一个临时想法
再让它回到原来的任务

这就像一个人公司里所有事情都找同一个人。不是这个人不会做，而是他被堵住了。

更麻烦的是上下文冲突。

排查服务器需要连续上下文：先看服务状态，再看日志，再看配置，再验证端口。中间如果插入一个完全无关的问题，虽然 Agent 能回答，但原来的排障节奏就断了。

所以万能 Agent 的问题，不只是记忆越来越杂，而是所有任务都挤在同一条线上。

我真正想要的是并行

我一开始的需求其实很朴素：

工作上的事，有一条专门工作线。

工作之外的事，有另一条工作线。

两边可以同时跑，不互相等待，也不互相污染上下文。

比如一个 Agent 在处理业务服务器告警时，我还可以问另一个 Agent 一个临时问题。一个 Agent 在检查脚本问题时，另一个 Agent 不会被迫停在旁边等。

这才是拆分的起点。

不是为了多几个机器人，而是为了减少等待和打断。

拆分不是复制一个新 Agent

一开始我也容易犯一个错：以为拆 Agent 就是把旧系统复制一份。

后来发现这样不对。

如果两个 Agent 都什么都管，那只是从一个杂物间变成两个杂物间。短期看好像更灵活，长期只会更乱。

真正有用的拆分，是按责任边界拆。

现在我更倾向于这样分：

工作 Agent：业务运维、监控、通知、订单链路、生产相关自动化
个人 Agent：工作之外的长期上下文、临时问题、个人事务和非生产环境事项

工作 Agent 不需要知道太多个人生活。

个人 Agent 也不应该默认背着所有工作生产环境。

这样分之后，我使用时也更清楚：这件事属于工作生产环境，就交给工作线；这件事不属于工作生产环境，就交给个人线。

少了一点“万能入口”的方便，但换来的是并行、清晰和安全。

这次迁移做了什么

确定方向后，我把一部分业务运维迁到了专门 Agent 上。

主要做了几件事：

• 在业务服务器上部署新的 Agent 环境；
• 整理业务服务器相关记忆、SOP、监控规则；
• 对齐模型和通知配置；
• 切换通知 bot；
• 把服务器脚本通知统一到新入口；
• 把 uptime、server health、数据 watcher 等任务迁到服务器侧 cron；
• 停用原来总控里的重复 cron，避免重复告警；
• 修复迁移后的收尾问题，比如服务重启、环境变量加载、历史 failed 状态。

这些动作本身不复杂。

真正重要的是判断哪些该迁，哪些不该迁。

订单生成没有直接迁走

这次迁移里，最重要的判断反而是：订单生成没有直接搬到服务器 Agent 上。

因为订单文件生成依赖很多本地资产：

• 本地订单模板；
• 本地图片库；
• 本地工作盘；
• 本地销售统计表；
• 本地运费清单；
• 人工检查和归档习惯。

所以服务器更适合负责入口：接收 webhook、验证、排队、留痕、通知。

真正生成文件，仍然适合由本地机器上的确定性脚本完成。

我现在更认可的结构是：

服务器：接收 webhook、验证、排队、通知
本地机器：拉取 pending 订单、生成文件、回写结果
Agent：查看状态、解释异常、辅助排障

订单生成不需要“聪明”，它需要稳定。

它要能重跑、能审计、能回滚。输入一样，输出就应该一样。失败了要能重试，重复执行不能产生脏数据。

这种任务更适合 Worker，而不是 LLM Agent。

一句话：任务不应该跟着 Agent 迁移，而应该运行在最适合它的位置。

我现在理解的三层结构

拆完之后，我对个人自动化系统的理解变成三层：

总控 Agent
→ 专职 Agent
→ 确定性 Worker

这三层不能混在一起。

把所有 cron、webhook、监控都塞给总控，它会变成单点故障。

把订单生成交给 Agent，可靠性会下降。

把生产权限给一个内容 Agent，安全边界会扩大。

稳定系统靠的不是“所有事情都智能化”，而是该判断的判断，该执行的执行。

什么时候该拆 Agent

我现在会用几个问题判断要不要拆：

第一，它会不会经常打断别的任务？

如果会，就值得拆。工作任务和非工作问题本来就不应该互相排队。

第二，它有没有独立上下文？

业务运维有自己的服务器、脚本、告警、SOP。工作之外的上下文也有自己的偏好、习惯和临时问题。混在一起只会增加噪音。

第三，它有没有独立权限边界？

工作 Agent 不该继承所有个人记忆。个人 Agent 也不该默认拥有所有工作权限。

第四，它失败时是不是需要单独排查？

如果出了问题你会自然地问“到底是哪条链路坏了”，那它就应该有清楚边界。

但不是所有东西都要拆成 Agent。

如果一个任务可以用脚本稳定完成，需要幂等、重试、日志和审计，那它更适合做成 Worker。

最重要的是写清楚“不负责什么”

每个专职 Agent 都应该有边界说明。

不一定复杂，但至少要写清楚：

Mission:
Owns:
Does not own:
Tools:
Memory scope:
Allowed actions:
Requires approval:
Logs:
Rollback:

这里面最重要的是 Does not own。

很多系统变乱，不是因为没人负责，而是因为谁都可以顺手负责一点。

Agent 也一样。如果不写清楚“不负责什么”，专职 Agent 很快又会变成新的万能 Agent。

结尾

这次拆分之后，我对 multi-agent 反而没那么兴奋。

我更关心三个问题：

• 工作流有没有少堵一点？
• 权限和上下文有没有更清楚？
• 任务有没有跑在最适合的位置？

现在的方向很简单：

工作归工作
非工作归非工作
判断归 Agent
执行归 Worker

这听起来不炫，但更可靠。

最终目标不是拥有一群 Agent，而是拥有一套不会互相堵住、可维护、可恢复的个人自动化系统。