子代理与多智能体协作:我如何用 Agent 团队维护博客

Words: 1120Read Time: 3 minLast edited: 2026-8-4
博客写到第三年,维护成本开始超过写作本身:旧文章要更新、错别字要校、主题代码要改、部署要盯。去年下半年 AI 编程工具的子代理(subagent)能力成熟后,我把博客维护拆给了一个「Agent 团队」,跑了小半年,聊聊怎么分工的,以及哪些地方其实不适合拆。

为什么要拆:上下文隔离

最早我就是一个主 Agent 干所有事,问题很快暴露:所有任务挤在同一个上下文里。让它改完主题 CSS 再校对文章,上下文里全是代码细节,校对质量肉眼可见地下降;而且长上下文费 token、容易跑偏。
子代理的核心价值不是「人多力量大」,而是每个子代理带着干净的上下文上场。校对代理的上下文里只有文章和校对规则,代码代理的上下文里只有仓库,互不污染。主代理只拿到它们返回的结论,自己的上下文保持精简。

我的分工

主代理负责编排:接需求、拆任务、派活、验收。下面四个专职:
  • 写作代理:按大纲出初稿,带博客的文体规范(第一人称、禁用 AI 腔)
  • 审校代理:只读不改,输出错别字、时间线矛盾、事实存疑清单
  • 代码代理:主题样式和脚本改动,能跑构建命令自己验证
  • 部署代理:只碰构建和发布,权限收到最小
每个子代理就是一个带角色提示词的定义文件,例如审校代理:

什么适合并行,什么必须串行

适合拆的:相互独立、输入明确的任务。比如同时审校 5 篇旧文章,5 个审校代理并行跑,几分钟全回来;又比如「给 20 篇文章批量生成摘要」这种天然可分的活。
不适合拆的:任务之间有强依赖,或者需求本身模糊。我试过让写作代理和审校代理「并行」处理同一篇新稿——审校拿到的是半成品,两边返工,比串行还慢。判断标准很简单:B 的输入依赖 A 的产出,就别并行。另外拆任务本身有成本:每个子代理都要重新加载背景,两分钟能写完的小段落,拆出去反而多花十分钟。

踩过的坑

  • 子代理没有主代理的记忆。派活时背景必须写全:文件路径、文体要求、边界条件。我一开始只写「校对一下这篇文章」,它把我博客里故意保留的港台译名全「修正」了
  • 两个代理别同时写同一个文件。并行写作时代码代理和写作代理同时改了同一篇带代码的文章,合并冲突搞了半天。现在的规矩:写文件的任务互斥,只读的任务随便并行
  • 主代理要验收,不能直接转发。子代理返回的结果主代理得抽查再汇总,有次审校代理漏报了一个明显的版本错误,直接转给我就丢人了
现在的状态:一篇文章从初稿到发布,我只做两件事——给大纲、终审,中间环节 Agent 团队自己转,周末维护时间从一天缩到两小时。多智能体不是银弹,但对「流程固定、角色清晰」的重复劳动,它是真的好用。
Loading...
© 2024 - 2026 ihuadz
中文