一、问题与背景多 Agent 协作是 Agent 工程里最难落地的方向之一。理论上让 BA、SA、PM 三类 Agent 协同完成一个项目听起来就像让三个不同职能的同事开个会对齐方案。但实际跑起来常见的情形是能力错配BA 的工具集里出现了修改数据库 schema但那是 SA 的活。沟通失控A 把任务交给 BB 不知道该用什么格式回于是自由发挥最终格式五花八门。角色漂移随着上下文变长原本是 BA 的 Agent 慢慢学会了做 SA 的事角色边界模糊。协同不可观测出了问题没人知道是 BA 错了、SA 错了还是交接错了。这些问题听起来眼熟吗没错它们本质上就是微服务架构里“服务边界不清晰、接口不契约、调用不可观测”的 Agent 翻版。只不过以前我们调试的是一个 HTTP 服务现在调试的是一个 LLM 推理服务——错误的现象随机根因更难指。根因是之前的多 Agent 框架只规定了谁是 Agent没规定Agent 能干什么、不能干什么、干了之后怎么交接。这个根因在过去两年中反复被验证几乎所有大型项目中的 Agent 谜题归根结底都是交接问题。A 输出了什么、B 如何解析、B 输出后 C 是否会重复同样的工作——这些问题在传统软件中是“接口”与“消息总线”问题在 Agent 时代被严重低估了。二、产品规格Agent Skill Warehousemcp.smartmoves.com.cn 提出了一种以角色化技能集为核心的协作模式每个角色对应一个 Skill 集合集合里同时定义能力、边界和交付契约。核心三个技能集技能集职责关键能力交付物BA-Master需求分析用户访谈模板、业务流程图、用例抽取需求文档 验收标准SA-Master方案设计架构选型、接口契约、技术风险评估方案文档 架构图PM-Master项目推进任务拆解、依赖梳理、风险跟踪计划文档 里程碑每个技能集都是一个独立 Skill遵循统一的四层结构指令 / 知识 / 执行 / 评测通过仓库发布和版本管理。三、技术架构协作流程在协议层做了三件事┌───────────┐ contract ┌───────────┐ contract ┌───────────┐ │ BA-Master │ ─────────→ │ SA-Master │ ─────────→ │ PM-Master │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ▼ ▼ ▼ Skill 仓库 Skill 仓库 Skill 仓库 (mcp.smartmoves.com.cn)契约驱动每个 Skill 在instruction/里定义自己的output_contract下一棒 Agent 据此解析结果不需要重新理解上下文。共享知识池所有角色读同一份业务背景知识但通过角色隔离指令确保只输出与自己职责相关的内容避免越界。交接可观测MCP 协议在调用层记录每一次交接平台能给出哪两个角色最常出错、哪个交接步骤最耗时等可观测数据。这样做的好处是角色边界由 Skill 而非 Prompt 定义。改了 Prompt 不会扩散到所有 Agent但改了 Skill 仓库里的output_contract所有下游都会同步感知。四、成果与收获落地这套模式后团队观察到的几个变化角色边界清晰化以前 BA Agent 偶尔会跑去做 SA 的事现在工具集层面就拦截了。交接从自由文本变成结构化数据下游 Agent 不再需要猜上游在说什么可以直接消费 JSON 字段。问题排查时间下降 70%过去跨角色失败要逐个 Agent 看 prompt现在直接 diff 两个 Skill 的output_contract几秒定位。角色可替换换一个新人来维护 SA-Master他只需要更新 Skill不用动任何代码其他角色照常工作。这套模式让多 Agent 协作从演示起来惊艳、生产起来拉胯走向了真正可控的工业级方案。重要的是这套模式不与特定框架绑定无论是 LangGraph、CrewAI 还是自研调度器只要能读取 Skill 目录中的指令与契约就能马上获得角色隔离与交接可观测能力。这意味着企业不需要推倒重来只要在现有 Agent 运行时中加载仓库里的三个 Master 技能集就能从自由发挥过渡到按角色交付。五、实践成果网站地址plan.smartmoves.com.cn这就是 BA-Master / SA-Master / PM-Master 三技能集驱动下的真实形态——一个由 Agent Skill Warehousemcp.smartmoves.com.cn支撑的智能规划平台三角色 Agent 在站点上完成从需求到方案的端到端协作访问即可看到完整的协作流水。站点上不仅能看到最终输出还能看到中间的交接记录谁在什么时间把什么交给了谁、下游是如何解析的、交接质量评分是多少。这种全链路可观测能力是传统聊天式 Agent 产品永远看不到的。
一、问题与背景多 Agent 协作是 Agent 工程里最难落地的方向之一。理论上让 BA、SA、PM 三类 Agent 协同完成一个项目听起来就像让三个不同职能的同事开个会对齐方案。但实际跑起来常见的情形是能力错配BA 的工具集里出现了修改数据库 schema但那是 SA 的活。沟通失控A 把任务交给 BB 不知道该用什么格式回于是自由发挥最终格式五花八门。角色漂移随着上下文变长原本是 BA 的 Agent 慢慢学会了做 SA 的事角色边界模糊。协同不可观测出了问题没人知道是 BA 错了、SA 错了还是交接错了。这些问题听起来眼熟吗没错它们本质上就是微服务架构里“服务边界不清晰、接口不契约、调用不可观测”的 Agent 翻版。只不过以前我们调试的是一个 HTTP 服务现在调试的是一个 LLM 推理服务——错误的现象随机根因更难指。根因是之前的多 Agent 框架只规定了谁是 Agent没规定Agent 能干什么、不能干什么、干了之后怎么交接。这个根因在过去两年中反复被验证几乎所有大型项目中的 Agent 谜题归根结底都是交接问题。A 输出了什么、B 如何解析、B 输出后 C 是否会重复同样的工作——这些问题在传统软件中是“接口”与“消息总线”问题在 Agent 时代被严重低估了。二、产品规格Agent Skill Warehousemcp.smartmoves.com.cn 提出了一种以角色化技能集为核心的协作模式每个角色对应一个 Skill 集合集合里同时定义能力、边界和交付契约。核心三个技能集技能集职责关键能力交付物BA-Master需求分析用户访谈模板、业务流程图、用例抽取需求文档 验收标准SA-Master方案设计架构选型、接口契约、技术风险评估方案文档 架构图PM-Master项目推进任务拆解、依赖梳理、风险跟踪计划文档 里程碑每个技能集都是一个独立 Skill遵循统一的四层结构指令 / 知识 / 执行 / 评测通过仓库发布和版本管理。三、技术架构协作流程在协议层做了三件事┌───────────┐ contract ┌───────────┐ contract ┌───────────┐ │ BA-Master │ ─────────→ │ SA-Master │ ─────────→ │ PM-Master │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ▼ ▼ ▼ Skill 仓库 Skill 仓库 Skill 仓库 (mcp.smartmoves.com.cn)契约驱动每个 Skill 在instruction/里定义自己的output_contract下一棒 Agent 据此解析结果不需要重新理解上下文。共享知识池所有角色读同一份业务背景知识但通过角色隔离指令确保只输出与自己职责相关的内容避免越界。交接可观测MCP 协议在调用层记录每一次交接平台能给出哪两个角色最常出错、哪个交接步骤最耗时等可观测数据。这样做的好处是角色边界由 Skill 而非 Prompt 定义。改了 Prompt 不会扩散到所有 Agent但改了 Skill 仓库里的output_contract所有下游都会同步感知。四、成果与收获落地这套模式后团队观察到的几个变化角色边界清晰化以前 BA Agent 偶尔会跑去做 SA 的事现在工具集层面就拦截了。交接从自由文本变成结构化数据下游 Agent 不再需要猜上游在说什么可以直接消费 JSON 字段。问题排查时间下降 70%过去跨角色失败要逐个 Agent 看 prompt现在直接 diff 两个 Skill 的output_contract几秒定位。角色可替换换一个新人来维护 SA-Master他只需要更新 Skill不用动任何代码其他角色照常工作。这套模式让多 Agent 协作从演示起来惊艳、生产起来拉胯走向了真正可控的工业级方案。重要的是这套模式不与特定框架绑定无论是 LangGraph、CrewAI 还是自研调度器只要能读取 Skill 目录中的指令与契约就能马上获得角色隔离与交接可观测能力。这意味着企业不需要推倒重来只要在现有 Agent 运行时中加载仓库里的三个 Master 技能集就能从自由发挥过渡到按角色交付。五、实践成果网站地址plan.smartmoves.com.cn这就是 BA-Master / SA-Master / PM-Master 三技能集驱动下的真实形态——一个由 Agent Skill Warehousemcp.smartmoves.com.cn支撑的智能规划平台三角色 Agent 在站点上完成从需求到方案的端到端协作访问即可看到完整的协作流水。站点上不仅能看到最终输出还能看到中间的交接记录谁在什么时间把什么交给了谁、下游是如何解析的、交接质量评分是多少。这种全链路可观测能力是传统聊天式 Agent 产品永远看不到的。
