从”AI编辑部”到可落地的多智能体平台：我用 Sage 复盘一次端到端内容生产

话题引子：量子位在《我用10块钱的「熟虾」，搞了个AI编辑部！》里展示了一个“浏览器里开箱即用的多智能体编辑部”工作流（总编/记者/编辑/校对/排版/运营）。我读完的第一反应是：这类 demo 一旦进入真实生产，最大的挑战不在“能不能跑”，而在“能不能稳定、可控、可扩展地跑”。

这篇文章我想借它做一个切入点，介绍我在做的 Sage 多智能体平台（开源仓库：https://github.com/ZHangZHengEric/Sage）：如果把“AI编辑部”当作一个典型的长程多步骤任务，那么 Sage 关注的是它背后的工程化底座——编排模式、可观测性、上下文预算、安全沙箱、技能/工具/MCP 的可插拔，以及跨端的工作台体验。

1. AI 编辑部这个范式，真正有价值的是什么？

量子位文章把“多智能体写作”拆成了明确的流水线角色：

• 总编：拆解选题、给提纲
• 记者：联网搜集资料
• 编辑：写初稿
• 校对：纠错+核事实
• 排版：排版+配图
• 运营：标题与发布

我认可这种拆解的核心价值：

1) 角色边界清晰：每个 Agent 的 prompt 更短、更稳定，越权概率降低。

2) 交接物显式化：提纲、素材包、文档链接、状态看板——这些都是可追踪的“中间产物”。

3) 可插拔：你可以替换某个环节的模型或工具，而不必推倒重来。

但进入“真实生产”，问题也马上出现：

• 失败如何重试？重试会不会污染上下文？
• 多个子任务并行时，状态如何一致？
• 工具调用可不可以审计？能不能限制权限？
• 任务跨小时运行，如何断点续跑？
• 复杂流程一多，prompt/脚本会不会变成新的“屎山”？

这正是我做 Sage 的出发点：把“多智能体 demo”变成“多智能体平台”。

2. Sage 是什么：一个生产级、多模式的多智能体编排框架

Sage 的定位不是“又一个 Agent Prompt 集合”，而是一个可落地的多智能体编排框架 + 跨端工作台。

仓库：https://github.com/ZHangZHengEric/Sage

Sage 里面我重点打磨了几件事：

• 多种编排模式：
  • TaskExecutor：顺序执行（适合流水线）
  • FibreAgent：并行协作（适合可并发的子任务）
  • AgentFlow：声明式工作流（适合复杂可维护流程）

• 可观测性：用 OpenTelemetry 把调用链路、步骤、耗时等沉淀下来，避免黑盒。

• Context Budget 管控：多步骤任务最怕上下文爆炸；Sage 把“token 预算”当一等公民。

• 安全沙箱：对有执行风险的代码/命令、文件访问做隔离（sagents.utils.sandbox）。

• Skills/Tools/MCP 可插拔：把能力来源标准化，把“工程整合成本”从每个项目里移出来。

下面这张概念图对应的是我在 Sage 里最常用的一种分层视角：

3. 用 Sage 复刻“AI编辑部”：我会怎么设计？

如果我要用 Sage 去实现量子位文章里的“AI编辑部”，我不会只写 6 段 prompt。

我会做三层建模：

3.1 角色层：6 个 Agent，人设=职责+权限

• 写作类（总编/编辑/校对）：限制联网、只读“资料包”
• 搜索类（记者）：允许联网，但强制输出“来源链接+引用段落”
• 发布类（运营）：限制写入路径、限制外发目标

这一步解决的是：越权、幻觉、权限风险。

3.2 流程层：用 AgentFlow 让交接变成“协议”

用声明式流程把每一步输入/输出固定下来，比如：

• outline.md
• sources.json
• draft.md
• final.md
• assets/（配图）

每一步都能做到：

• 可重试
• 可回放
• 可断点

3.3 系统层：可观测性 + 上下文预算 + 沙箱

• 每一步的耗时、失败点在哪里
• 当搜索结果很多时，如何压缩成“资料包”
• 对执行命令/写文件做白名单

这一步解决的是：稳定性、可维护性。

4. “熟虾式开箱即用” vs “本地自建”：我更关心哪几个指标

量子位文章把 ArkClaw 类产品称为“熟虾”，我觉得形容得很贴切：

• 你不再自己搭环境、装技能、配飞书、做权限
• 你用更低成本获得一个可以跑的工作流

但如果我站在“要把它用在团队/业务里”的角度，会更关心这些指标：

1) 可迁移性：我能不能从 A 平台迁移到 B 平台？流程是不是可移植？

2) 可控性：我能不能限制某个 Agent 只能读写指定目录、只能调用指定工具？

3) 可观测性：出了问题能不能定位，是模型不行、工具不行、还是流程设计不行？

4) 可扩展性：从 6 个角色扩到 20 个角色，是否还能维护？

这张图是我脑中最常见的对比：

我的观点是：

• “熟虾”让更多人第一次跑通多智能体工作流
• 而 Sage 这类框架更关注：如何让它在更长时间、更复杂场景里持续跑通

两者并不矛盾，甚至可以互相借鉴。

5. 我为什么坚持做 Sage：多智能体要走向“工程体系”

多智能体系统很容易陷入两个极端：

• 只追 demo：看起来很酷，但不可复用、不可审计、不可维护
• 过度工程：把简单问题复杂化，流程重到跑不动

Sage 的目标是走中间路线：

• 有“编排框架”的工程化底座
• 但保持足够模块化，能快速搭建和迭代

如果你对 Sage 感兴趣：

• GitHub：https://github.com/ZHangZHengEric/Sage
• 文档（仓库 README 里也有入口）：https://wiki.sage.zavixai.com/

我接下来也会把“AI 编辑部”做成一个可复用的 Sage Demo：

• 一个 AgentFlow 描述文件
• 一组可替换的 Skills/Tools（搜索、事实核查、排版、发布）
• 一套可观测性面板和失败重试策略

到时候就不是“给我一个标题我帮你写”，而是：给我一个目标，我给你一条可维护的生产流水线。

引用

• 量子位：我用10块钱的「熟虾」，搞了个AI编辑部！（2026-03-13）https://www.qbitai.com/2026/03/387116.html
• Sage（开源）：https://github.com/ZHangZHengEric/Sage