1. 项目概述一个为AI产品经理设计的自动化多智能体协作系统如果你是一名AI产品经理或者正在尝试用AI Agent来辅助完成从需求到上线的完整产品开发流程那么你一定遇到过这样的困境单个AI Agent能力有限而让多个Agent协同工作又常常陷入混乱。需求理解不清、任务拆解不细、原型与代码脱节、问题打回成本高昂……这些痛点每天都在消耗我们的精力。今天要分享的是我在深度实践后重构并落地的一套名为“Harness_Multi-Agent_AI_PM”的Skill体系。它不是一个简单的工具集合而是一个高度解耦、流程清晰、具备自我校准能力的多智能体协作框架。其核心目标是模拟一个成熟产品团队的完整工作流将“产品想法”自动化、高质量地转化为“可交付的软件模块”。这套体系基于WorkBuddy平台构建通过定义五个明确的阶段、七个各司其职的Agent角色以及一套名为“Harness”的精细化控制机制实现了从需求澄清、原型设计到编码开发、测试验收的全流程自动化管理。简单来说它就像给你的AI团队聘请了一位资深的产品总监Orchestrator并配备了需求分析师Analyst、架构规划师Planner、原型设计师Designer和工程指挥官Runner等专业角色。每个角色职责清晰通过严格的上下文共享和阶段门控机制协同工作最大程度避免了传统多Agent协作中常见的“方向漂移”和“返工地狱”。无论你是想从零开发一个个人工具还是为现有系统添加复杂功能这套体系都能提供一个稳定、可预测的自动化产出路径。接下来我将为你彻底拆解它的设计哲学、核心架构以及每一个实操细节。2. 架构核心五阶段流程与三段式解耦设计2.1 为什么是“五阶段”—— 模拟真实产品开发的生命周期很多自动化工具失败的原因在于试图用单一流程解决所有问题或者流程阶段划分模糊导致Agent在不同性质的工作间跳跃上下文混乱。本体系采用的“五阶段流程”P1-P5是对经典产品开发流程需求-设计-开发-测试-交付的抽象和优化每个阶段都有明确的输入、输出和“完成定义”。第一阶段需求→分析→拆解这是项目的奠基阶段目标是产出清晰、无歧义的“开发宪法”。此阶段由pm-analyst和pm-planner两个Agent接力完成。pm-analyst的核心工作是“追问”它被强制要求与用户进行至少三轮对话以挖掘模糊需求背后的真实约束、业务目标和用户场景。其产出goal.md文件是一个结构化的目标对象而非一段自然语言描述。随后pm-planner接手将宏观目标颗粒化为可执行的模块。这里的“模块”是关键设计每个模块包含不超过5个功能点及明确的验收标准并构建出模块间的依赖有向无环图。这个阶段的严谨性直接决定了后续所有工作的效率。第二阶段原型UI定型这是本体系最具创新性的“校准基石”阶段。在投入一行代码之前pm-designerAgent会基于P1的产出生成可交互的低保真原型通常是HTMLCSS、组件树和页面路由图。这个原型需要经过Orchestrator和用户的共同确认。其价值在于用一个极低的成本相比写代码让所有参与者——用户、产品经理、后续的开发Agent——对“要做什么”达成视觉和交互层面的一致共识。它能有效避免开发完成后才发现“这不是我想要的”巨大浪费。第三阶段架构→开发→测试只有当前两个阶段被确认后开发工作才会启动。pm-runner作为本阶段的指挥官负责调度pm-coder,pm-researcher,pm-writer等子Agent。它依据P1产生的依赖图进行智能调度优先开发无依赖或低依赖的模块实现并行化。更重要的是每个开发任务都会“注入”P2确认的原型作为对齐依据确保代码实现不偏离设计初衷。第四阶段打回循环任何自动化流程都无法保证一次成功。P4定义了问题出现时的标准化处理流程。其核心规则是“最小必要回退点”决策。例如如果测试发现某个功能与原型不符问题可能被定位到P3的开发环节但如果发现是原型本身无法满足核心需求则可能需要回退到P2甚至P1。这个决策由全局视角的Orchestrator做出避免了执行层Agent如pm-runner因局部信息做出全局性误判。第五阶段整合交付这是收尾阶段以模块为单位进行交叉验收和整合测试。Orchestrator会组织相关Agent对每个模块进行评审并生成最终的复盘报告将本次项目中的经验如某个技术选型的优劣、某个模块的拆解方式沉淀到系统的“记忆”中用于优化未来的项目。注意这五个阶段是强顺序的存在“阶段门控”。P2必须等待P1完成且产出被审核通过P3必须等待P2的原型被确认。这种阻塞设计虽然看似降低了并发度但极大地保障了流程的确定性和产出质量是避免AI项目陷入混沌的关键。2.2 “三段式解耦”如何解决传统Orchestrator的臃肿问题在早期的多Agent系统中Orchestrator编排器常常成为一个“上帝类”它既要理解需求又要拆解任务还要调度资源监控进度导致逻辑复杂、难以维护且容易成为性能瓶颈。本体系的核心改进就是“三段式解耦”将Orchestrator的职责大幅精简。瘦身后的Orchestrator它的新定位是“流程交警”和“信息枢纽”。主要职责只剩四件1.监听与同步监控各阶段Agent的状态和产出。2.阶段切换决策根据阶段完成标准决定是否推进到下一阶段或触发打回。3.上下文收集与分发维护并更新“上下文池”确保正确的信息在正确的阶段被正确的Agent访问。4.用户交互作为系统对外的统一接口。它不再直接处理需求分析、任务拆解、代码编写等具体业务。这种设计让Orchestrator变得轻量、稳定焦点完全集中在流程控制上。职责分发到专业Agentpm-analyst专职负责“需求澄清”。它的技能树点在了对话、追问和结构化信息提取上确保初始输入的质量。pm-planner专职负责“颗粒化拆解”。它将分析师产出的清晰目标转化为机器可理解、可执行的模块化蓝图和依赖关系图。pm-runner专职负责“调度执行”。它根据规划师提供的蓝图像一个工程经理一样管理子Agent资源池处理任务调度、依赖解决和异常监控。通过这种解耦每个Agent都可以独立优化和迭代。例如你可以替换一个更强大的需求分析模型给pm-analyst而无需改动pm-planner或pm-runner的逻辑。系统的复杂度和灵活性得到了很好的平衡。2.3 上下文池与HEARTBEAT项目协同的“中央神经系统”多Agent协作最大的挑战之一是信息孤岛和状态不一致。本体系通过“上下文池”和“HEARTBEAT双层记忆”机制来解决。上下文池这是一个虚拟的、结构化的项目共享存储区。它不是一个聊天历史而是一系列有严格权限控制的Markdown和资源文件。例如goal.md由pm-analyst写入其他Agent大多只读确保项目目标不被随意篡改。prototype/目录由pm-designer写入pm-coder只能读取以对齐开发。这种细粒度的读写控制模拟了真实团队中不同角色对文档的权限管理保证了信息的权威性和一致性。HEARTBEAT双层记忆项目级记忆记录全局进度、阶段状态、关键技术决策、已知风险和问题。它就像项目的仪表盘让Orchestrator和用户一眼就能看清项目全貌。任务级记忆记录每个具体任务如T001: 实现用户登录API的详细状态、执行上下文、中间输出和健康度。这帮助pm-runner进行精细化的任务管理和故障恢复。这个“中央神经系统”确保了即使某个Agent中途失败或被重启它也能从上下文中快速恢复工作状态不会丢失关键项目上下文这是实现长周期、复杂项目自动化的基石。3. 核心Agent角色详解与实操配置3.1 各Agent的职责边界与技能设计每个Agent都是一个独立的Skill其能力通过SKILL.md文件定义。理解每个Agent的精确职责和交互方式是有效使用该体系的关键。pm-orchestrator (主控器)核心职责流程控制、上下文同步、决策路由。它是整个系统的启动器和协调者。触发词“开发”、“实现”、“做一个”、“搭建”。当用户在WorkBuddy中输入这些关键词时Orchestrator会被激活。实操要点它的Skill指令集主要包含阶段状态机管理、上下文文件读写、以及生成其他Agent的调用指令。它自己不进行复杂推理而是基于规则和当前上下文做出流程判断。例如当它发现prototype/目录下生成了新的wireframe.html且component-tree.md完整就会触发“原型验收”流程。pm-analyst (需求分析师)核心职责将模糊的用户需求转化为结构化的、可衡量的项目目标。关键动作“至少三轮追问”。这是硬性规定。第一轮通常澄清核心功能What第二轮挖掘用户场景和约束Who, When, Where第三轮确认非功能需求和成功标准How well。例如用户说“做个记账App”分析师会追问“是个人用还是家庭共享”、“需要支持多币种吗”、“数据同步是必须的吗”。产出product.md(项目背景)、goal.md(结构化目标)、requirements.md(需求清单)。goal.md的格式至关重要通常包含项目名称、核心用户、主要功能、技术约束、成功指标等字段。pm-planner (规划师)核心职责将宏观目标拆解为可并行开发的原子模块并理清依赖关系。核心产出modules.md模块列表。每个模块格式为## [模块名]、功能点、验收标准、输出物。dependency-dag.md依赖有向无环图。使用Mermaid语法绘制必须确保无环否则会导致调度死锁。skills-needed.md列出完成各模块所需的子Skill如需要调用特定的数据库操作Skill、图表绘制Skill等。避坑经验模块粒度的把握是难点。粒度过粗如“实现前端”无法指导开发粒度过细如“实现登录按钮点击事件”会产生海量任务管理开销剧增。实践中一个模块应对应一个可以独立测试、价值交付明确的子系统如“用户认证模块”、“数据导出模块”。pm-designer (原型设计师)核心职责在编码前产出可视化的交互蓝图。工作流读取goal.md和modules.md- 绘制用户交互流程图 - 设计组件树定义可复用的UI组件- 定义页面路由 - 生成可交互的线框图。工具链通常利用AI生成Mermaid图来描述流程生成HTML/CSS/JS来构建一个静态但可点击的原型。这个原型不需要美观但必须完整覆盖所有核心用户路径。价值这是最重要的“防跑偏”环节。我曾在一个项目中跳过此阶段直接进入开发结果coder对“仪表盘”的理解与用户预期大相径庭导致全部返工。自此之后我强制要求所有项目必须经过P2。pm-runner (执行指挥官)核心职责调度子Agent按计划执行开发任务。核心能力DAG调度器解析dependency-dag.md识别可以并行开发的模块批次。策略引擎处理子任务执行中的阻塞如前序任务失败、超时和资源竞争。健康监控监控子Agent如pm-coder的“健康度”一个综合了响应速度、任务成功率等指标的分数低于阈值如30会向Orchestrator告警。上报机制它无权自行决定将任务打回至更早阶段。当遇到无法解决的问题如依赖的技术库突然不兼容它只能“上报”问题给Orchestrator由后者做出全局决策。实操命令它的Skill中包含类似spawn pm-coder with task T001 and context [module_details]的指令并能注入诸如“请参考prototype/login.html中的设计”这样的上下文提示。3.2 Harness为每个Agent戴上“方向盘”Harness是本体系另一个精妙的设计。你可以把它理解为每个Agent的“个性化驾驶舱配置”。它不是一个Skill而是一组控制Agent行为的约束和参数。每个Agent在harnesses/目录下都有一个对应的配置文件如analyst-harness.md。主要配置项包括mode: 工作模式如strict严格遵循流程、creative允许更多创造性发散。max_turns: 最大对话轮次。对于pm-analyst这至少是3对于pm-coder可能设置为10以允许更多的调试交互。allowed_tools: 允许该Agent使用的工具集。例如pm-researcher可能被允许使用网络搜索和文档读取工具而pm-coder则被限制只能使用代码编辑器和终端。constraints: 行为约束。例如为pm-planner设置约束“单个模块功能点不得超过5个”“依赖图必须为有向无环图”。配置示例 (planner-harness.md):# Planner Agent Harness Configuration **Mode:** structured **Max_turns:** 5 **Allowed_tools:** - File read/write (context_pool) - Mermaid diagram generator - Markdown formatter **Constraints:** 1. Each module MUST have no more than 5 functional points. 2. Each functional point MUST have a clear, testable acceptance criterion. 3. The dependency graph MUST be a Directed Acyclic Graph (DAG). 4. If a circular dependency is detected, re-plan the module decomposition. 5. Output must strictly follow the templates in shared/references/.通过Harness你可以精细地调控每个Agent的“性格”和能力边界防止它们越界或做出不符合预期的行为让整个系统运行得更稳定、更可控。4. 完整工作流实操从零构建一个Markdown笔记应用让我们通过一个具体案例串联起整个五阶段流程。假设我们的目标是“开发一个支持Markdown编辑、实时预览、本地存储和标签管理的桌面笔记应用”。4.1 第一阶段实操需求澄清与模块拆解用户输入在WorkBuddy中我们输入“帮我做一个Markdown桌面笔记应用要能实时预览存在自己电脑上还能打标签。”Orchestrator触发识别到“做一个”这个触发词Orchestrator被激活。它初始化上下文池创建product.md文件并生成指令spawn pm-analyst with user_request。pm-analyst工作第一轮追问“您说的‘桌面应用’具体指哪种技术形式比如Electron跨平台、Tauri更轻量还是原生系统应用”用户回答“用Electron吧希望能在Windows和Mac上都能用。”第二轮追问“‘实时预览’是边输入边渲染还是需要一个手动切换的按钮标签是平铺的还是支持嵌套层级”用户回答“边输入边渲染最好。标签支持平铺就行但希望能给一个笔记打多个标签。”第三轮追问“本地存储方面除了笔记内容和标签需要支持附件如图片吗数据备份有什么考虑”用户回答“暂时不需要附件。备份功能最好有能手动导出所有数据为单个文件就行。”产出pm-analyst将对话结果结构化写入goal.md。内容大致如下# Project Goal: Markdown Desktop Note App **Core User**: Individual users needing a lightweight, offline-first note-taking tool. **Key Features**: 1. Rich Markdown editing with live preview (side-by-side or inline). 2. File-based local storage (notes saved as .md files in a user-designated folder). 3. Tag management system: multiple tags per note, tag filtering and browsing. 4. Data export: ability to backup all notes and tags into a single archive file. **Tech Stack**: Electron React (for UI) Node.js (for file system operations). **Success Metrics**: - Launch app and create a new note within 3 seconds. - Typing in editor reflects in preview with 100ms latency. - Tags persist correctly after app restart.Orchestrator审核Orchestrator检查goal.md确认关键要素功能、约束、指标齐全然后spawn pm-planner。pm-planner工作读取goal.md开始功能拆解。模块化分组M01: 应用框架与窗口管理Electron主进程/渲染进程搭建基础窗口创建。M02: 笔记数据模型与存储定义Note对象id, title, content, tags, createdTime实现基于本地文件系统的CRUD操作。M03: Markdown编辑器与预览器集成一个Markdown编辑器组件如CodeMirror实现一个Markdown渲染组件如Marked.js并实现实时同步逻辑。M04: 标签管理系统Tag对象的CRUD笔记-标签的多对多关系维护提供按标签过滤笔记的接口。M05: 用户界面与交互主界面布局笔记列表、编辑区、标签栏实现上述模块的UI组件并串联交互。M06: 数据导入导出实现将整个笔记库打包为单一JSON或压缩文件的功能。构建依赖DAGgraph TD M01[应用框架] -- M02[数据存储]; M01 -- M03[编辑器]; M01 -- M05[UI]; M02 -- M03; M02 -- M04[标签系统]; M02 -- M06[导入导出]; M03 -- M05; M04 -- M05; M04 -- M02;注意M04标签系统依赖于M02数据存储来持久化标签数据同时M02也依赖M04来维护笔记-标签关系这里存在一个互相依赖。pm-planner需要识别并解耦这个环例如将“关系维护”作为一个独立的子模块或接口。产出modules.md,dependency-dag.md,tasks.md将模块进一步拆分为具体任务如M02-T01: 定义Note数据模型以及skills-needed.md可能需要electron-builder的打包Skill。4.2 第二阶段实操原型设计作为开发锚点Orchestrator触发P2审核通过P1产出后spawn pm-designer。pm-designer工作读取goal.md和modules.md。绘制交互流程图描述用户从打开App、创建笔记、编辑、打标签到导出的完整路径。设计组件树App ├── MainLayout │ ├── Sidebar (NoteList, TagFilter) │ └── Workspace │ ├── EditorPanel (MarkdownEditor) │ └── PreviewPanel (MarkdownPreview) ├── NoteEditorModal └── ExportModal生成低保真可交互原型使用简单的HTML、CSS和JavaScript构建一个静态页面。这个页面有侧边栏列表、一个文本输入框模拟编辑器、一个渲染区域模拟预览、一个标签输入框和几个按钮。虽然不能真正保存数据但可以模拟点击笔记列表切换编辑区内容、输入Markdown后预览区实时变化等交互。原型验收Orchestrator将原型链接呈现给用户。用户操作后确认“对我想要的布局和交互大概就是这样。”这个确认动作至关重要它锁定了后续开发的视觉和交互基线。4.3 第三阶段实操基于原型的并行开发Orchestrator触发P3原型确认后spawn pm-runner。pm-runner启动步骤1技术架构讨论。pm-runner可能会同时spawn2-3个pm-coder让它们分别提出实现M02数据存储的技术方案如直接用Node.jsfs模块或用lowdb这类轻量数据库。pm-runner收集方案后上报给Orchestrator由Orchestrator或用户做出选择。步骤2安装Skills。根据skills-needed.md确保必要的子Skill如文件操作、Electron API调用等已就绪。步骤3DAG批次调度。分析dependency-dag.md发现M01应用框架是根节点无依赖。因此它首先spawn pm-coder执行任务T001“搭建Electron基础项目结构”。在给coder的指令中会明确注入“UI布局请严格参照prototype/wireframe.html中的设计”。步骤4并行与监控。一旦M01完成M02和M03就可以并行开发。pm-runner会持续监控任务状态和子Agent健康度。如果某个coder卡住或健康度下降策略引擎会尝试重启任务或更换Agent实例。步骤5测试与文档。每个模块开发完成后pm-runner会调度pm-coder为模块编写单元测试。同时pm-writer会被调度来编写用户使用文档和API文档。4.4 第四、五阶段问题处理与完美收尾假设在测试M03编辑器时发现实时预览在笔记内容超过1000行时出现明显卡顿。问题上报负责测试的pm-coder或监控到性能问题的pm-runner将问题上报给Orchestrator附上性能日志。打回决策Orchestrator分析问题。这属于“实现未达到非功能需求性能”且问题定位在M03模块的实现上。根据“最小必要回退点”规则它决定打回至P3阶段但仅针对M03模块的优化任务。它不会回退到P2或P1。重新调度Orchestrator更新任务状态pm-runner重新spawn一个pm-coder或pm-researcher来处理“编辑器大数据量性能优化”这个新子任务。优化方案如虚拟滚动、防抖渲染被实施并验证。整合交付所有模块通过验收后进入P5。Orchestrator组织pm-coder和pm-writer进行交叉检查确保模块间接口兼容最终打包生成可执行文件。同时生成一份复盘报告记录“Markdown实时预览在大数据量下需做性能优化”的经验并沉淀到HEARTBEAT中供未来项目参考。5. 常见问题、排查技巧与进阶配置5.1 部署与使用中的典型问题问题1Orchestrator没有正确触发后续阶段。排查首先检查context_pool目录下对应阶段的产出文件是否完整且格式正确。例如P1到P2的转换依赖于goal.md和modules.md的存在。使用命令查看文件内容和权限。解决确保pm-analyst和pm-planner的Skill指令正确写入了这些文件。有时可能是文件路径权限问题确保WorkBuddy有写入权限。问题2pm-runner调度任务时出现循环依赖错误。排查检查dependency-dag.md文件。使用Mermaid渲染或简单分析确认图中是否存在环。例如A依赖BB又依赖A。解决这是pm-planner的拆解逻辑问题。需要手动或通过指令让pm-planner重新规划模块。通常的解决方法是引入一个第三方模块或接口来打破循环或者将两个紧密耦合的模块合并。问题3子Agent如pm-coder执行任务失败健康度持续下降。排查查看该任务对应的progress/TXXX.md文件里面通常有执行日志和错误信息。同时检查skills-needed.md中要求的子Skill是否已正确安装并授权。解决根据错误信息修复。如果是网络问题或API限额等待后重试。如果是Skill缺失安装对应Skill。pm-runner的策略引擎应能根据失败类型瞬时错误、配置错误、逻辑错误决定重试、上报还是更换Agent。问题4原型P2被确认后开发出的功能与原型感觉不一致。排查对比prototype/中的交互说明与progress/中相关开发任务的描述。检查pm-runner在spawn coder时是否在指令中明确注入了原型对齐要求。解决强化pm-designer的原型输出规范要求其不仅提供视觉还要在component-tree.md中详细描述组件的状态和行为。同时优化pm-runner的指令模板确保原型约束被清晰传递。5.2 性能优化与扩展建议Harness调优根据项目类型调整Harness参数。对于探索性项目可以将pm-analyst和pm-planner的mode设为creativemax_turns调高允许更多发散。对于严谨的工程项目则设为strict。上下文池优化对于大型项目上下文文件可能变得很大。可以考虑为pm-coder等子Agent配置只加载其所需模块的上下文片段而不是整个文件以节省Token消耗并提升推理速度。自定义子Agent体系是开放的。如果你经常需要开发特定类型的功能如地图集成、支付接口可以专门训练或配置一个pm-map-specialist或pm-payment-integrationAgent并在pm-planner的skills-needed.md和pm-runner的调度配置中注册它。经验库建设重视P5的复盘报告。将这些报告结构化后存入一个知识库并让pm-analyst和pm-planner在启动时能够检索相似历史项目的经验可以实现“越用越聪明”的集体学习效果。5.3 安全与合规性实践在设计和配置Agent的Harness时务必加入安全约束文件系统访问严格限制每个Agent可以访问的目录范围特别是pm-coder防止其误操作或恶意代码影响系统。网络访问对于pm-researcher可以限制其可访问的域名或要求通过安全的代理服务进行搜索。内容过滤在最终输出阶段特别是pm-writer生成用户文档时可以添加一层内容安全检查过滤不当信息。权限隔离充分利用上下文池的读写权限控制遵循最小权限原则。例如pm-coder绝不应该有权限修改goal.md。这套“Harness_Multi-Agent_AI_PM”体系通过严谨的流程设计、清晰的职责划分和精细化的控制机制将多智能体协作从一场充满不确定性的“布朗运动”变成了一条可控、可预测、可复现的“工业化流水线”。它需要一定的学习和配置成本但一旦跑通对于标准化程度较高的产品功能开发其效率提升和质量保障是单点AI工具无法比拟的。