从进程编排到多智能体协作：低门槛构建 AI 应用实践

一、为什么做一个 AI 应用，demo 阶段就这么慢

很多开发者都有类似体验：只是接一个大模型 API 做问答，半天就能跑通；一旦需求变成”多步骤、多智能体协作、还要读写 Word/PDF 文档”，复杂度立刻飙升。

问题往往不出在模型本身，而出在框架的抽象层。常见的智能体编排框架，光是要理解链、智能体、工具、记忆、输出解析这几个核心抽象，初学者一周都嫌少；有的新概念文档跟不上，有的靠一堆 YAML 配置驱动，轻量方案深入定制又不顺手。工程师做 demo 慢，本质是被框架的抽象层拖住了。

于是出现了一个反向思路：不引入重型框架，把”能跑智能体的命令行程序”当成一个子进程来用。只要能启动子进程、能解析 JSON，任何语言都能把它接成自己的智能体引擎——Java、Go、Python、Node 都行，不绑 SDK 版本，不绑语言。

这个思路成立，需要三个前提条件同时满足，缺一不可：

• 智能体可被当作子进程启动。 启动一个进程就能跑一次任务，不需要常驻服务、不需要长连接握手。
• 输出是结构化的。 标准输出直接吐出结构化事件流（工具调用、文本、步骤开始、步骤结束，一行一条 JSON），下游可以逐行解析，而不是去正则匹配自然语言。
• 模型被抽象成”供应商/模型”字符串。 切换模型只是改一个参数，不涉及代码改动或依赖重装。

下面逐一展开，说明这三点为什么能撑起一个通用智能体后端。

二、把智能体做成子进程：三个关键能力

2.1 子进程化：一次调用就是一次进程生命周期

把智能体封装成子进程，最大的好处是边界干净。任务开始时启动，任务结束时退出，中间的状态不会污染宿主应用；崩溃了也只影响这一次调用，不会拖垮整个服务。

对于宿主程序来说，它只需要做三件事：

1. 拼装命令行参数（模型、智能体名、提示词）；
2. 启动子进程并读取标准输出；
3. 按行解析 JSON 事件，映射成自己的业务回调。

这种模式天然适配批处理场景：一个目录下几百份文档，就可以用几百次进程调用去处理，天然可并行、可重试、可限流。相比之下，把智能体嵌进宿主进程内部的方案，往往需要自己实现线程池、状态清理和异常隔离。

2.2 结构化事件流：让下游能”读懂”智能体的每一步

自然语言输出适合人看，不适合程序消费。结构化事件流的价值在于，它把智能体的执行过程拆成可枚举的事件类型，例如：

• step_start / step_finish：标记一次推理步骤的开始与结束；
• tool_use：表示调用了某个工具，并携带工具名与参数；
• text：模型输出的文本片段。

示意性的解析逻辑（伪代码）：

import json, subprocess
proc = subprocess.Popen(
    ["<agent-cli>", "run", "--model", "<provider>/<model>",
     "--format", "json", "--agent", "<agent-name>", "<prompt>"],
    stdout=subprocess.PIPE, text=True
)
for line in proc.stdout:
    event = json.loads(line)
    if event["type"] == "tool_use":
        handle_tool(event["name"], event["input"])
    elif event["type"] == "text":
        append_text(event["content"])
    elif event["type"] == "step_finish":
        mark_step_done(event)

有了这套事件协议，宿主程序就能做很多”框架级”的事：统计工具调用次数、记录中间产物、在特定事件上中断或插入人工审核。框架能做的事，事件流同样能做，而且更透明。

2.3 模型抽象成字符串：切换成本降到一行

当模型被抽象为 provider/model 形式的字符串时，切换模型就只是一次参数替换：

<agent-cli> run --model <provider-a>/<model-x> --format json "<prompt>"
<agent-cli> run --model <provider-b>/<model-y> --format json "<prompt>"

这对工程实践意味着：可以按任务复杂度选择不同档位的模型，简单抽取用轻量模型，复杂判断用推理能力更强的模型；也可以在某个模型不可用时快速降级。不绑 SDK 版本这点尤其关键——很多框架的升级会因为底层 SDK 破坏性变更而卡住，而子进程模式把这种耦合彻底切断了。

三、多智能体：把”角色”做成可注册的条目

单智能体解决的是”一次推理 + 若干工具调用”的问题；但真实任务往往需要不同视角的协作。一个常见的做法是维护一份智能体注册表，把不同职责的智能体固化成具名条目，例如：

• 重型执行者：承担主要的生成与改写工作；
• 批判者：以怀疑视角审查前一步的结论，专门找漏洞；
• 分析判断者：做归纳、比较与决策建议；
• 文档检索者：负责从资料库中定位依据。

调用方式可以简化到反直觉的程度——只需在命令行里指定智能体名称：

<agent-cli> run --agent <critic-agent> "<prompt>"

这种设计的工程价值在于协作拓扑可以被显式编排。例如一个典型的三段式流程：

1. 执行者根据输入产出初稿；
2. 批判者对初稿提出质疑与修改点；
3. 分析判断者综合两者给出最终结论。

每一步都是独立进程，输入输出都通过文件或标准输入输出传递，天然可观测、可回放、可单步重跑。比起在一个进程内用回调串联多个智能体，这种”进程级编排”在调试时优势明显：哪一步出问题，单独重跑那一步即可。

四、一个非代码场景：检验科 SOP 的年度更新

上述能力并不只服务于代码任务。举一个与编程完全无关的例子：医院检验科通常有几百份标准操作程序（SOP）文档，每年需要对照最新国家标准与厂商说明书做更新。

这个任务的难点非常典型：

• 体量大：几百份文档，人工逐份比对成本高；
• 依据多：要同时参考国家标准、行业规范、设备说明书；
• 需要判断：不是简单替换文字，而是要判断哪些条款发生了变化、是否需要修改流程；
• 需要留痕：每处修改都要有依据来源，便于审核。

用多智能体流程拆解，可以设计成：

阶段	承担角色	输入	输出
资料定位	文档检索者	标准/说明书库、SOP 编号	相关条款片段
差异比对	重型执行者	原 SOP + 条款片段	差异清单初稿
质疑复核	批判者	差异清单初稿	疑点与反驳意见
结论输出	分析判断者	初稿 + 疑点	修订建议与依据

每一步都通过子进程调用完成，输出结构化事件流，宿主程序据此生成审计记录：哪份文档、哪一条、依据哪份标准的哪一段、由哪个智能体在什么时候提出。这种留痕能力，恰恰是自然语言式输出难以稳定提供的。

五、落地建议与边界

这套思路并非万能，落地时有几点需要提前考虑：

1. 进程启动开销：每次调用都启动进程，适合批处理而非高频交互。若需要低延迟对话，应考虑常驻服务形态。
2. 并发控制：数百份文档并行处理时，需要自己做并发上限与队列管理，避免把下游模型服务打满。
3. 结果校验：结构化事件流保证的是”过程可解析”，不代表”结论正确”。关键业务场景仍需人工复核环节，尤其是涉及规范与合规的文档。
4. 提示词与角色设计：多智能体的效果高度依赖角色定义的清晰度。批判者要真的”唱反调”，分析判断者要真的”做取舍”，否则会退化成多个智能体说同样的话。
5. 成本与模型选型：不同阶段可以用不同档位模型，检索与抽取用轻量模型，判断与复核用更强模型，在效果与成本之间取平衡。

六、小结

当智能体可以被当作子进程启动、当输出是结构化事件流、当模型只是两个字符串时，构建 AI 应用的门槛就被大幅拉低了：

• 语言不限，任何能启动进程、解析 JSON 的技术栈都能接入；
• 版本不绑，框架升级不再成为阻塞项；
• 编排显式，多智能体协作变成可观测、可回放的流程；
• 场景不限于代码，文档处理、合规比对、资料整理同样适用。

对于追求快速交付的团队而言，与其先花一周啃抽象概念，不如先用这套”进程 + 事件流 + 注册表”的思路把流程跑通，再根据实际瓶颈决定是否引入更重的编排层。工具的价值不在于抽象有多优雅，而在于它能否让开发者把注意力放回业务本身。