DWG · IDANT-JRN-006 · AGENTS JOURNAL
AGENTS JRN-006 · 13 分钟

1 天到 1 小时:咨询 AI 智能体的多代理工作流设计

为什么不是一个大模型搞定,而是六个小模型协作

这篇笔记关于一个具体场景 —— 用多智能体协作把 1 天的咨询分析压缩到 1 小时
但不是"换个更快的 LLM"那么简单。
下面 8 个段落覆盖:单 Prompt 失败、多智能体拆分、DAG 编排、长期记忆、工具调用、可观测性、上线工程化。

AI 是工具,工程化才是答案 —— 这是这个项目最重要的认知。

SINGLE PROMPT · MULTI AGENT
01
SECTION

真实痛点:咨询行业的"经验黑盒"

讲师做企业咨询报告的真实流程:上午调研、下午整理 14 份问卷、晚上对照 20+ 张专业表单做交叉分析、写报告评语。从数据进来到报告出来,1 个工作日打底

但更深的问题不是"慢",是 质量不可控。报告质量上下限取决于讲师个人经验:高水平讲师能在数据里挖出"销售费用增长 32% 但人效下降 8% 的隐含管理问题";新讲师只能写"销售费用增长,建议关注"。

规模化的瓶颈不是培训新讲师 —— 是经验本身 装不进文档。这是 AI 智能体的真正机会:把"高水平讲师的隐性流程"显性化、模块化、可复制。

02
SECTION

为什么不是一个大模型搞定 — 单 Prompt 的崩溃边界

最直觉的方案:把 14 份问卷 + 20 张专业表单全塞进一个长 prompt,让大模型直接出报告。

GPT-4 / Claude 3.5 都能容纳 100K+ tokens,理论上够。但能容纳并不等于能正确处理。长 prompt 里:模型注意力稀释、重要信息被淹没;推理跳层"忘记"中间步骤;输出风格漂移,前 5 页严谨后 5 页变水;一个调整重跑全流程,迭代效率为零。

工程上更糟的是 不可调试:报告里某段评语错了,你不知道是哪部分输入害的。整个 prompt 是一个黑盒。

这个方案 demo 阶段能跑,上线必死。

03
SECTION

多智能体设计:六个专业分工胜过一个万能

咨询行业的 SOP 早就给出了拆分线索 —— 六大维度,每个维度一个独立智能体。

模块一 基础情况(数据核验 + 信息补全)/ 模块二 经营业绩(财务数据 + 战略历史)/ 模块三 瓶颈诊断(增长曲线 + 关键阻碍)/ 模块四 战略定位(行业坐标 + 竞争格局)/ 模块五 激励机制(组织架构 + 薪酬结构)/ 模块六 执行力(流程效率 + 落地阻力)。

每个智能体只负责一个维度,prompt 短、上下文聚焦、输出格式可锁。职责越窄,质量越高

更重要的:每个智能体可以 独立迭代。如果"模块三 瓶颈诊断"需要升级,只改这一个 prompt,其他五个不动。这种隔离性是单 prompt 方案永远拿不到的。

04
SECTION

工作流编排:DAG 而非流水线

六个智能体不是顺序串行 —— 它们之间有 依赖关系

模块一是其他所有的输入前提(基础数据未确认前其他模块跑出来都是错的);模块二三四五六 可以并行执行(互不依赖);最终把六个模块的产出综合成一份报告。

工程上用工作流引擎编排:LangGraph / Temporal / 自研 DAG 调度器。关键不是用什么引擎,是把依赖关系显式化 —— 而不是埋在 prompt 里靠 LLM 自己琢磨。

DAG 编排的额外好处:能并行的智能体并行跑,省下大块墙钟时间。这也是"1 天到 1 小时"里最大的一份贡献。

05
SECTION

长期记忆:上下文不在 prompt 里

咨询智能体要"记住"很多东西:客户公司的过往对话、历次访谈记录、行业基准数据、上次报告的结论。这些 不能塞 prompt —— 累积下去 prompt 会爆炸。

正确架构是 三层外置记忆:向量库(Milvus / Weaviate)存历史对话和文档片段,按语义检索;图谱(Neo4j)存组织架构和业务关系,按实体遍历;关系库(PostgreSQL)存财务数据和 KPI 时序,按时间和维度查询。

智能体按需检索(RAG),只把 相关的 5% 内容 拉进当前 prompt。这样既保留长期记忆,又不污染当前推理。

记忆的难点不是"存",是"取"。让智能体知道"什么时候该去查记忆库"是 prompt 工程的核心。

06
SECTION

工具调用:让智能体真"调用"而不是"回答"

LLM 的两个公认弱点:精确计算 + 实时数据

财务比率(毛利率 / ROE / 应收账款周转天数)—— 让 LLM 算?错位率 30% 以上。给它一个 Python 工具,让它"调用"计算器,结果 100% 准。

行业基准、企业工商信息、政府公报数据 —— LLM 训练截止时间之前的值不一定准。给它一个 API(国家统计局 / 工商信息 / 行业研究库),让它"查询"。

工具 schema 用 JSON Schema 严格定义。每个工具有 input / output 类型校验,调用失败有 retry / fallback。智能体不"扮演"会计、它"调用"会计软件

07
SECTION

可观测性:调试 6 个智能体的工程难题

单 prompt 出错只有 1 个失败点,多智能体出错有 6 个。没有可观测性就别上多智能体

工程上必须可观察:每个智能体的 input / output / system prompt 全记录;工具调用的请求 / 响应 / 错误码;DAG 上每个节点的运行时长 / 状态;失败 retry / 降级路径。

工具:Langfuse / LangSmith / 自研 Trace 系统(基于 OpenTelemetry)。

报告里某段评语错了 —— 5 分钟定位到是模块三 prompt 漂移、还是工具调用拿错数据、还是模块一基础数据不全。

Demo 阶段能跑、生产环境必崩 —— 多智能体不是"组合几个 prompt"那么轻松。

08
SECTION

1 天到 1 小时:不是模型快了,是流水线对了

最后一个常被误解的点:这个项目的关键不是"用 AI 替代讲师"。

讲师角色变了,但没消失。原来一整天 亲手做 六大维度分析;现在 1 小时 审核 + 修改 六个智能体的产出。

讲师变成"智能体的总编辑":审 AI 拿数据准不准、看 AI 推理逻辑对不对、改 AI 评语口吻(让报告读起来像专家而非机器)、加 AI 学不到的"现场感受"(访谈时客户的犹豫与表达)。

效率提升 8 倍来自 模块并行 + 工程化 —— 不是模型本身变快了。

AI 智能体是工具,工程化才是答案。这是这个项目和 90% 的"AI 替代人"叙事最大的差别。

SUMMARY · 总结
Cheat Sheet

8 条多智能体工程取舍

  1. 01·别用一个大模型扛 1 天的工作 — 长 prompt 必崩
  2. 02·按业务 SOP 拆智能体 — 6 个专业分工胜过一个万能
  3. 03·DAG 编排显式依赖 — 不要把依赖埋在 prompt 里
  4. 04·三层外置记忆 — 向量库 + 图谱 + 关系库 各司其职
  5. 05·RAG 按需检索 — 只把相关 5% 拉进当前 prompt
  6. 06·精确计算交给工具 — LLM 不会算账
  7. 07·可观测性是底线 — 没 Trace 别上多智能体
  8. 08·讲师不是被替代,是变成"智能体的总编辑"

多智能体的工程取舍,本质是 把"人的隐性流程"变成"系统的显性架构"
单 prompt 是黑盒,多智能体是白盒。
白盒能调试、能迭代、能扩展 —— 这是它在 B 端落地的真正护城河。

青莲 · idant