P1 AIP
多智能体编排:让多个角色 Agent 一起做分析
单 Agent 是"一个人干活",多智能体是"拉一个分析小组开会"。你只提一句"Q3 营收为什么下滑",系统用 LLM 把任务拆成多个子任务、按角色(销售 / 财务 / 供应链 / 通用)分给不同的 Agent 并行分析,最后融合成一份归因报告。看完这 3 个故事,你就知道四种策略怎么选、Agent 怎么注册、结果怎么追溯。
业务分析师
IT 管理员
数据工程师
多智能体
任务分解
结果融合
共 3 个故事
能 / 不能速览
✅ 这个主题能做
- POST /api/v1/orchestrations 创建编排任务,LLM 自动把任务分解成子任务(description/required_role/priority/depends_on)
- 四种策略:sequential(顺序)/ parallel(并行,默认)/ leader_follow(主从)/ debate(辩论)
- 按角色匹配 Agent:required_role → capabilities 语义打分 → general 兜底 → 负载均衡
- 内置 4 个角色 Agent(财务 / 销售 / 供应链 / 通用),admin 可增删改、设优先级与并发
- LLM 结果融合:把各子任务结论合成一份整合报告(debate 含争议仲裁)
- 任务/子任务全量落库,审计事件 ORCHESTRATION_TASK,admin 可导出声明式 YAML 制品
⛔ 这个主题做不了
- 子任务执行是"LLM 直呼 + 角色 System Prompt",不复用 tools.Executor 工具管线(V3 待办)
- 子任务不能执行 SQL / 调用工具——只做 LLM 文本分析,查数请用单 Agent 或 NLQ
- 无前端拖拽编排画布(有 OrchestratePage / AgentsPage 页面),无人工审批(requires_approval)
- LLM 分解失败时会降级为"单子任务交给通用 Agent",不做多次重规划
- 无结果溯源(trace_id 决策链)与异步任务队列,创建为同步执行
适用角色
本主题面向三个角色:
- 业务分析师 / 经营分析(李经理、王姐):发起多视角归因分析,是编排任务的主要消费者。
- IT 管理员(赵工):注册/更新/注销角色 Agent、调优先级与并发、导出声明式 YAML,是 Agent 资产的管理者。
- 数据工程师(张工):看子任务分配是否合理、判断"为什么某任务交给通用 Agent",参与 prompt / 能力标签调优。
能力速览(能做什么)
任务分解
LLM 把"Q3 营收下滑归因"拆成多个子任务,每个子任务带 required_role / priority / depends_on;LLM 失败时规则兜底单子任务。
四种策略
sequential(按依赖顺序)、parallel(无依赖并发,默认)、leader_follow(Leader 计划 + Worker 执行 + 汇总)、debate(双视角交锋 + LLM 仲裁)。
角色 Agent
4 个内置角色(财务/销售/供应链/通用)带中文 System Prompt 与能力标签;matchAgent 按语义打分 + 负载均衡选人。
结果融合
fuseResults 把各子任务结论融合成整合报告(report + sub_results),debate 策略含争议点标注。
资产化
任务/子任务/Agent 三表落库 + ORCHESTRATION_TASK 审计;admin 导出声明式 YAML(agent_definitions 缓存)供 Apollo 部署。
调整指南(怎么调整)
- 选策略:子任务有先后依赖用 sequential;子任务相互独立、要快用 parallel(默认);要"一个主导 + 多专家执行"用 leader_follow;要"正反交锋 + 仲裁"用 debate。
- 手动指定子任务:请求体里传 sub_tasks 数组(description/required_role/priority/depends_on),跳过 LLM 分解,结果更可控。
- 调 Agent 匹配:子任务描述里带上领域词(销售/财务/库存…),matchAgent 的 roleKeywordScore 打分才准;通用 Agent 优先级低(5)作兜底。
- 增删角色 Agent:admin 调 POST /orchestrations/agents(注册)、PUT /agents/:id(改 System Prompt/优先级/并发)、DELETE /agents/:id(软删)。
- 共享上下文:请求体 context 传给子任务 prompt,可放公司背景、指标口径等公共信息。
- 看结果追溯:GET /orchestrations/:id 看每个子任务的 agent_name / status / result_summary,判断是哪路结论主导了融合报告。
做得好的场景
多智能体编排在"需要多视角交叉论证"的分析场景最有价值:
- 归因分析:营收/利润下滑,销售、财务、供应链各自从本领域出结论,再融合成完整归因。
- 决策前听证:debate 策略让"提价派"和"降价派"正反交锋,LLM 仲裁给出平衡结论。
- 新业务评估:通用 Agent 综合多维度信息出结构化评估报告。
- 模板化复用:固定一组子任务定义(sub_tasks)反复跑,结论可比、可追溯。
限制与不足
以下是明确的边界,使用前先知道:
- 子任务不碰工具:只做 LLM 文本分析,不能查库/调 API;要真实数据结论请先 NLQ/单 Agent 拿数,再把数放进 context 给编排。
- 依赖外部 LLM:分解、子任务、融合都要调 LLM;无 key 时任务会失败(没有规则生成真实结论)。
- LLM 分解可能不稳:子任务粒度不可控,关键场景建议手动传 sub_tasks。
- 无审批/无画布:不能插入人工审批节点,前端是表单式(OrchestratePage),无拖拽画布。
- 同步执行:创建请求内跑完,任务量大时 HTTP 响应时间长;无后台异步队列。
场景故事
故事 1
李经理发起"Q3 营收下滑归因",并行让销售与财务 Agent 各出一份结论再融合
场景:并行归因
角色:业务分析师
耗时:约 10 分钟
- 背景
- 李经理是销售总监,Q3 营收比上季度下滑了 12%,董事会周四就要听归因。以前他要分别约销售、财务开会,凑齐各自主观判断再手工汇总。这次他打开多智能体编排页(/orchestrate),输入一句"Q3 营收下滑归因分析",选 parallel 策略,让系统自己分派。
- 传统做法对比
- 以前"多视角归因"等于开三场会:销售说市场不好、财务说口径变了、供应链说缺货,最后靠人拍脑袋拼结论,一场归因复盘要 1~2 天。现在一个请求同时派给销售、财务两个角色 Agent,各自按领域分析,几分钟拿到融合报告。
- 角色
- 业务分析师 / 经营分析(李经理,发起任务者)。
- 操作步骤
-
- 登录 AIP(admin / admin1),打开多智能体编排页 /orchestrate(或直接调接口)
- 创建任务:POST /api/v1/orchestrations,description="Q3 营收下滑归因分析",strategy="parallel"
- 等待同步执行完成,查看返回的任务视图(sub_tasks + result_summary)
- GET /api/v1/orchestrations/:id 查看每个子任务的 agent_name / status / result_summary
- 系统响应
- LLM 把任务分解为"销售视角"与"财务视角"两个子任务,分别匹配 sales_agent 与 finance_agent 并行执行,再融合成报告:
{
"code": 0,
"data": {
"orchestration_id": "9d1f...", "description": "Q3 营收下滑归因分析",
"strategy": "parallel", "status": "completed", "agent_count": 2,
"sub_tasks": [
{ "description": "从销售视角分析 Q3 营收下滑原因", "required_role": "sales",
"status": "completed", "agent_id": "...", "agent_name": "销售分析 Agent",
"result_summary": "销量下降 12%,主要来自华东区手机线,其中中端机型出货同比 -30%..." },
{ "description": "从财务视角分析 Q3 营收下滑原因", "required_role": "finance",
"status": "completed", "agent_id": "...", "agent_name": "财务分析 Agent",
"result_summary": "Q3 均价同比下降 8%,促销折扣率上升 5pct,收入端承压..." }
],
"result_summary": "综合销售与财务双视角:Q3 营收下滑 12%,主因华东区手机线销量下滑(-30%)叠加均价走低,建议聚焦中端机型补货与折扣收紧。",
"created_by": "admin"
},
"trace_id": "..."
}
- 结果洞察
- 两个角色 Agent 各出结论、互不干扰,融合报告把"量跌 + 价跌"两个根因都讲全了——比单 Agent 只给一个视角全面得多。李经理还能展开看每个子任务的 result_summary,知道结论来自谁,汇报时有据可依。
- 调整建议
- 若还想要供应链视角,把任务描述写细("结合销售、财务与供应链三视角")或手动传 sub_tasks;把已知数据(如销量表)放进 context 字段,子任务分析会更实;子任务间有依赖时改用 sequential。
- 动手试一试
- 登录:admin / admin1。页面路径:/orchestrate 多智能体编排。输入内容:description="Q3 营收下滑归因分析",strategy="parallel"。预期结果:返回 sub_tasks(销售/财务角色 Agent)与融合 result_summary;GET /orchestrations/:id 可查各子任务详情。
- 限制提示
- 子任务是 LLM 文本分析,不查真实数据——把数据放 context 才能让结论有据;LLM 分解的子任务粒度不可控,重要场景建议手动传 sub_tasks;无 key 时任务失败。
故事 2
辩论策略:"提价增收"还是"降价走量"?两个视角交锋,LLM 仲裁给结论
场景:辩论仲裁
角色:业务分析师
耗时:约 15 分钟
- 背景
- 王姐是业务分析师,公司手机线毛利率连续两季下滑。管理层在"提价保住毛利"和"降价抢回份额"之间僵持。她用 debate 策略创建任务,让系统模拟正反两个视角的观点交锋,最后由 LLM 仲裁出一个可落地的建议。
- 传统做法对比
- 以前这种策略辩论靠开会吵,谁嗓门大听谁的,往往没有结构化结论;现在 debate 策略自动生成"提价派"与"降价派"两个视角的子任务,各自摆论据,LLM 按逻辑仲裁,结论可追溯。
- 角色
- 业务分析师(王姐,发起辩论者);通用 Agent(仲裁方)。
- 操作步骤
-
- 登录 AIP,进入多智能体编排页
- 创建任务:POST /api/v1/orchestrations,description="手机线应提价保毛利还是降价抢份额?",strategy="debate"
- 等待执行完成,查看返回的融合报告(含争议标注)
- GET /orchestrations/:id/result 获取最终仲裁结果
- 系统响应
- debate 策略生成"正反两个视角"的子任务并行分析,LLM 仲裁融合:
{
"code": 0,
"data": {
"orchestration_id": "7ab2...", "description": "手机线应提价保毛利还是降价抢份额?",
"strategy": "debate", "status": "completed",
"sub_tasks": [
{ "description": "正方视角:提价保毛利", "status": "completed",
"agent_name": "通用分析 Agent", "result_summary": "提价 5% 可回补毛利率约 3pct,但需求弹性大时销量 -8%..." },
{ "description": "反方视角:降价抢份额", "status": "completed",
"agent_name": "通用分析 Agent", "result_summary": "中端机型竞品压价,降价 8% 可保份额但毛利 -4pct..." }
],
"result": "仲裁结论:建议分机型差异化——旗舰提价 5%、中端保持价格并控折扣,预计整体毛利率 +1.5pct 且份额不丢。争议点:需求弹性假设差异较大,需以销售数据验证。",
"created_by": "admin"
}
}
- 结果洞察
- 正反两方论据都摆出来了,仲裁结论"分机型差异化"既不极端也不和稀泥,还标出了争议点(需求弹性假设)——这正是 debate 策略的价值:把决策前提显性化。王姐把这份报告连同争议点一起发给管理层,会前信息差就消除了。
- 调整建议
- 把已知的销量/价格弹性数据放 context,两方论据会更具体;若想指定视角文案,可在 context 传 perspective_a / perspective_b;仲裁依赖 LLM 质量,重要决策建议人工复核报告中的量化假设。
- 动手试一试
- 登录:admin / admin1。页面路径:/orchestrate。输入内容:description="手机线应提价保毛利还是降价抢份额?",strategy="debate"。预期结果:返回两个视角子任务 + 仲裁报告;GET /orchestrations/:id/result 看完整 result。
- 限制提示
- debate 两视角默认都由通用 Agent 执行(不自动绑定销售/财务角色);争议仲裁是 LLM 判断,不保证与现实财务模型一致;无真实数据输入时结论偏"推理演练"性质。
故事 3
赵工注册"库存分析 Agent"、调优先级并导出声明式 YAML 制品
场景:Agent 资产化
角色:IT 管理员
耗时:约 15 分钟
- 背景
- 赵工是 IT 管理员。供应链同事总做库存周转分析,但内置的 supply_chain_agent 是通用描述,专深度不够。他准备注册一个专属的"库存分析 Agent"(带更专业的 System Prompt 与能力标签),并把整套 Agent 配置导出成 YAML 制品,准备后续交给 Apollo 声明式部署。
- 传统做法对比
- 以前"新增一个角色"要么改代码重新发版、要么写文档手工交接配置;现在 admin 调一个接口注册 Agent,保存即生效,还可一键导出 YAML 制品归档、复用、跨产品交接,Agent 从"代码里的常量"变成"可管理的资产"。
- 角色
- IT 管理员(赵工,Agent 资产管理);数据工程师(张工,帮忙写 System Prompt)。
- 操作步骤
-
- 登录 admin,调 GET /api/v1/orchestrations/agents 查看现有 4 个内置 Agent
- POST /api/v1/orchestrations/agents 注册"inventory_agent"(role=supply_chain,自定义 System Prompt + capabilities)
- PUT /api/v1/orchestrations/agents/:id 把它的 priority 调高、max_concurrency 设为 5
- GET /api/v1/orchestrations/agents/export 导出声明式 YAML(agent_definitions.yaml)
- 系统响应
- 注册成功返回 Agent 实体;导出返回 YAML 文本并幂等缓存到 agent_definitions 表:
-- POST /orchestrations/agents 返回(示意)
{ "code": 0, "data": { "name": "inventory_agent", "display_name": "库存分析 Agent",
"role": "supply_chain", "capabilities": ["inventory","turnover","stock_out"],
"model_id": "deepseek-v4-flash", "is_enabled": true, "priority": 20, "max_concurrency": 5 } }
-- GET /orchestrations/agents/export 返回 YAML(节选)
agent_definitions:
- name: inventory_agent
display_name: 库存分析 Agent
role: supply_chain
capabilities: [inventory, turnover, stock_out]
system_prompt: "你是资深供应链分析助手,擅长库存周转率、缺货率、呆滞库存分析..."
priority: 20
max_concurrency: 5
eval_suite_ref: aip_rag_golden_20
- 结果洞察
- 新 Agent 注册后立即参与编排匹配(priority=20 高于内置 supply_chain_agent 的 10),库存类子任务会优先派给它;YAML 制品导出后既可归档版本管理,也是跨产品(Apollo 声明式部署)的交接介质。赵工把它放进制品库,团队协作从"口口相传"变成"一份文件"。
- 调整建议
- System Prompt 写清专业口径(如"库存周转率=销售成本/平均库存"),子任务分析质量更高;能力标签与内置 roleKeywords 对齐可提升 matchAgent 打分;导出 YAML 后可在 Apollo 侧消费为部署制品(契约已就绪,Apollo 侧为后续批次)。
- 动手试一试
- 登录:admin / admin1。接口:GET /orchestrations/agents、POST /orchestrations/agents(注册自定义 Agent)、PUT /orchestrations/agents/:id(改优先级)、GET /orchestrations/agents/export(导出 YAML)。预期结果:新 Agent 出现在列表;导出文件含该 Agent 定义;用它再建一个 supply_chain 类任务,子任务应派给它。
- 限制提示
- Agent 注册/导出均需 admin 权限;删除为软删(is_enabled=false),不物理删除;export 导出的是当前 orchestration_agents 的全部 Agent,导出缓存写入 agent_definitions 表为 best-effort;Apollo 侧消费为后续批次。
常见问题
多智能体编排和单 Agent 是什么关系?
并存互补:单 Agent(/agents/tasks)是规则两步链,经工具管线真实查数(SQL 执行/RLS/脱敏/审计);多智能体编排(/orchestrations)是"角色化 LLM 分析小组",子任务为 LLM 直呼、不碰工具。要真实数据用单 Agent / NLQ,要多视角归因用编排。
四种策略怎么选?
sequential:子任务有先后依赖;parallel(默认):子任务独立、要快;leader_follow:一个主导 + 多专家执行,Leader 汇总;debate:正反交锋 + LLM 仲裁。拿不准就用 parallel。
子任务是怎么拆出来的?
默认由 LLM(orchestration_decompose)把任务描述拆成子任务 JSON;LLM 失败时规则兜底为单子任务交给通用 Agent。也可以手动传 sub_tasks 数组,完全跳过分解。
Agent 是怎么被选中的?
matchAgent 按子任务的 required_role 精确匹配;未指定时按 capabilities 语义关键词打分(roleKeywordScore),再 general 兜底;同角色候选用 pickBest(未饱和优先 > 优先级高优先 > 负载低优先)。
子任务为什么不走工具管线?
这是 2026-08-10 评审裁定的边界:编排 v0.1 定位"角色化 LLM 分析",子任务直接 LLM 直呼 + 角色 System Prompt,无参数校验/超时/审计管线;复用 tools.Executor 管线列为 V3 待办。
结果能追溯吗?
能。GET /orchestrations/:id 返回每个子任务的 agent_name / status / result_summary / error,融合报告在 result 字段;审计事件 ORCHESTRATION_TASK 记录任务级成败。完整 trace_id 决策链(结果溯源)属 V3 规划。
主题小结
一句话:多智能体编排把"一个人干活"升级成"一个分析小组开会"——LLM 拆任务、按角色派 Agent、四策略执行、融合成报告。记住边界:子任务不碰工具(要数据先 NLQ/单 Agent)、依赖外部 LLM、无审批与画布、LLM 分解粒度不可控。归因、听证、多视角评估是它的主场。