把「AI 帮我干活」做成产品：多 Agent 协作编排的五个产品决策

多 Agent 协作编排系统：一句话提需求，PM Agent 出方向、拆任务，执行 Agent 写代码/写文档，验收 Agent 做机器校验，所有状态落在一张表里，界面实时可见，桌面端双击就能打开。它服务的是「一个人带项目、没有运维预算、还要把东西发出去给别人用」的场景，所以定位不是「更强的 AI 代码助手」，而是一支可编排的虚拟团队，加上一套能回看的过程。

功能清单可以列很长，但真正决定这个产品长什么样的，是几个产品决策：先解决哪个痛点、把人工关口设在哪、MVP 划到哪、用什么指标证明有用。这篇不聊框架细节，讲这几件事是怎么被定下来、又怎么被反复推翻的。

一、先定义问题：AI 协作的痛点不是「生成得不够快」#

大多数人用 AI 干活的起点是「一个对话框，一路问到底」。用久了会发现，卡住的从来不是生成速度，而是三件很产品的事：

• 状态不可信：这件事谁在做、做到哪一步、验收过没有，全靠自己记；AI 说「已完成」，你并不知道它到底改了几个文件；
• 成本不可控：每轮把整段上下文重发一遍，钱花在哪、哪次调用贵，说不清；做优化也只能凭感觉；
• 人失控：全自动不放心，全手动不省事。中间缺一个「它先出方案、我确认、再执行」的关口。

把这三条翻译成产品目标，就有了后面的全部设计依据：

再叠加四条硬约束，产品边界基本就定死了：本地优先（数据不出机器，离线也能跑通闭环）、零运行时依赖（不装环境就能用）、可分发（双击打开，而不是先开终端敲命令）、可观测（token、缓存、耗时、失败原因都要看得见）。

这四条看起来是技术约束，其实是用户约束：目标用户是「一个人带项目、没有运维预算、还要把东西发出去给别人用」的角色——独立开发者、小团队负责人、想把 AI 引到真实工作里的业务同学。为他们做产品，就不能要求他们先具备平台工程能力。

二、用户旅程：一条主路径，五个由人把关的关口#

主路径是一条线：提需求 → PM 澄清 → 方向确认 → 自动拆卡上板 → 执行 → 验收 → 登记沉淀。产品设计的重点不在「让 AI 多做一步」，而在把人的判断放在最值钱的位置。

这里有两个刻意的产品选择。

第一，确认之后不自动跑。 方向确认只生成任务卡，必须再点「开始执行」才动。多一次点击，换来的是「我要在它开始烧钱之前看一眼任务拆得对不对」——对个人用户来说，这个停顿比任何炫技都值钱。

第二，人不写代码，但要写三样东西：方向、验收标准、边界。 拆解交给 Agent 是为了省时间，但「什么算做完」必须由人定义成可机器判定的条目（文件在不在、JSON 能不能解析、端口能不能起来、界面关键区域是否非空）。一旦验收标准写成「感觉差不多了」，后面所有的自动化都会退化成自我表扬。

三、MVP 划界：先做闭环，不做平台#

这类产品最容易死在「什么都想要」：既要做多 Agent 协商，又要做多租户，还要做插件市场。做法是先划掉，再补上：

明确写进「非目标」的有四条，写下来是为了拒绝的时候有依据：不做多租户/多人权限，不做任务截止日期与到期提醒（任务卡模型里没有 due），不做容器级隔离执行（留接口不现在做），不做移动原生 App（先做响应式）。

为什么先做「可信状态」而不是更性感的「Agent 互相协商」？因为用户的第一次失望一定发生在「它说做完了，但其实没做完」，而不是「Agent 之间不会开会」。先修掉会让人立刻放弃的问题，再谈体验升级。

四、五个关键产品决策#

决策 1：只给用户一条状态线

界面上的看板是「投影」，真正的状态只在任务登记表里，所有变更走同一个入口：校验状态机、幂等去重、写事件、原子落盘。用户不需要理解这套机制，他只需要一个结果——看到的就是真的，刷新、重启、崩溃之后还是真的。这条决策换来的是一个很朴素的产品体验：不出现「界面说完成了、任务其实卡住了」这种信任崩塌。

当时还有两条更省事的路，都没走：前端直连状态（点了就变，反馈最快，但刷新就回退）；每个 Agent 各写各的文件（开发最省事，但出问题没人说得清是谁改的）。

代价是所有写都必须过这一个入口：想加个功能顺手改状态是不行的，得先定义命令、补状态机校验、想清楚幂等键。单写入口同时也是性能约束点——1,000 张卡时 GET /api/state 的 p95 还是 23.8ms，靠的是每条命令只复制被改的那张卡，而不是整表深拷。

决策 2：把「重复说话」当作成本项来管

多 Agent 系统的成本大头不是调用次数，而是每次调用重复发送的上下文。于是上下文被拆成三层：不变的人设与约定放最前（跨任务复用），半静态的共享结论放中间，当前任务与上游材料放最后。配合「工具结果先截断落盘、只回灌摘要 + 路径」，把上下文体积和任务复杂度解耦。

效果是可测量的：同一前缀的第二次调用命中 95.0% 的提示 token（384/404），冷启动那次是 0；6 张卡的中型项目优化后整体命中率从 74.8% 提到 90.4%。更重要的发现是结构性问题：单任务步数从 8 步拉到 16 步以上，整体命中率能从 74% 量级升到 92% 量级——也就是说，「任务拆多大」是一个产品决策，不是技术细节。卡拆得太碎，每张卡都要付一次「首次调用」的全价。

否掉的是两个极端：不做分层，整段重发——最简单，但每次调用都在为同样的内容重复付费；上向量库做「智能压缩」——听起来高级，但本地优先不能假设有外部向量服务，零依赖也装不进嵌入模型运行时，而且压缩本身要花一次调用，等于还没省先花。分层前缀的好处是纯客户端规则，不换模型、不加依赖就能生效。

代价是它把约束反向压到了产品上：卡不能拆太碎。一张卡如果只跑三四步，前面省下的前缀钱又被首调吃回去，所以拆卡规范里写了「一张卡覆盖一组相关产物 + 多重验收，目标 16 步以上」——这条看着像工程规范，其实是成本策略。

决策 3：验收标准先于执行，且由机器判定

这里坚持不让 Agent 自己宣布完成。验收是三层：机器校验（文件存在、格式可解析、能编译、能启动、交付包解压后入口可跑）→ 独立 QA 评审 → 人工兜底。验收失败不是无限重试，而是派生一张修复卡、让原卡依赖它，修完自动重新验收；同类失败反复出现就熔断转人工，附上「继续自动修 / 人工完成 / 调验收标准」三个选项。

否掉的三条路都很常见：让 Agent 自报完成（最省事，但「界面全绿、文件是空的」就是这么来的）；失败就无限重试（看起来最努力，实际是把同一处错误重放 N 次，钱花了问题还在）；只让大模型当裁判（能读懂语义，但读不出「文件到底在不在、端口到底起没起来」）。

代价是每个任务的准备成本更高：验收标准要由人写成可机器判定的条目，交付冒烟要真的启动应用、真的点进关键路径，一轮比「让 AI 自己说做完」慢得多。换来的是最重要的那条产品承诺：「完成」= 有一条可复查的证据链，而不是一句 completion。

决策 4：冲突必须可见，而不是被静默覆盖

多个 Agent 并行时最贵的错误是「两个 Agent 改了同一个文件，谁也没说」。产品的处理方式不是禁止，而是把它变成一个需要人决定的卡片：授权本次写入 / 改派给负责该文件的人 / 跳过。用户看到的是「有个冲突等你决定」，而不是第二天发现改动没了。

否掉的另外两条：干脆不并行——最安全，但那就退回成串行跑单，多 Agent 的意义没了；后写覆盖先写——实现最简单，代价是有人一晚上的改动会静默消失，而且事后查不出来。

代价是流程会停下来等人：出现冲突时任务卡在那，直到有人点。这是有意接受的成本——宁可停一分钟，也不要第二天发现改动没了。

决策 5：发不出去的软件等于没做

最后一公里被当成产品指标，而不是打包细节：双击即开、单实例、服务假死自动重启、隧道断了自动重连、升级不删用户数据。现在一个便携包 88.9MB，冷启动 609ms，运行内存 51.7MB。这些数字不酷，但它们决定了「用户会不会第二次打开」。

这里否掉的方案最多，也最容易被低估：单文件 SEA（单个 exe）——体积小、一个文件很漂亮，但它的「开窗口」依赖系统 Chrome/Edge 的 --app，本机实测不稳定，只能降级成可选兜底；NSIS / portable 自解压安装器——最符合「正常软件」的习惯，但它会解压到 %TEMP%，在临时目录异常的环境里直接报错，还可能弹「无法验证发布者」的 UAC；纯网页服务——零分发成本，但用户得先理解端口和启动命令，本地文件权限、打开目录这些桌面能力也用不上。所以在 Electron 宿主与单文件 exe 之间选了前者：体积换稳定窗口，是这一层唯一划算的交换。

代价是体积：分发包百兆级，换的是双击即用和稳定窗口。对一个「一个人带项目、没有运维」的用户来说，这个交换划算——他不会因为体积小而多打开几次，只会因为打不开而再也不打开。

五、怎么证明它有用：一个北极星 + 三个护栏#

这类产品最怕「演示很顺、用起来没有」。因此定了一个北极星指标和三个护栏，全部能从事件日志与接口里直接算出来，不靠主观感受：

另外两个工程侧数字用于自查，不对外当卖点：3 个项目并行相对顺序执行有 2.9× 加速（1,541ms → 531ms，mock + 150ms 模拟延迟下测得）；1,000 任务规模下 GET /api/state 的 p95 是 23.8ms。数字都标了口径——演示环境的数据不能当生产结论用。

六、踩过的坑，和它们改掉的产品设计#

坑 1：「Agent 说完成了」是最贵的假象

早期版本里 Agent 提交一段总结就算完成，结果出现「界面全绿、文件是空的」。改法不是写更严厉的提示词，而是把判定权从模型手里拿走：完成必须由机器证据说话，评审意见不能绕过硬门。这条改动之后，删掉了大量「请确保」「务必」之类的提示词——能被机器判定的标准，不要靠嘱咐。

坑 2：静默失败比报错更伤产品

写域冲突、合并冲突早期都是「静默跳过」，用户只看到任务卡住了。现在的规则是：任何可能需要人知道的分支，都必须留下可见的痕迹（决策卡、阻塞原因、冲突现场路径）。对用户来说，「有个东西等你决定」比「什么都没发生」可信得多。

坑 3：任务颗粒度是产品问题，不是执行问题

一开始需求拆得很碎，结果每张卡都要付出一次完整的上下文成本，命中率掉到 74% 量级，而且频繁切换上下文。后来把「一张卡覆盖一组相关产物 + 多重验收」写成拆卡规范，单卡目标 16 步以上——成本和返工一起降下来。拆卡规范本质上是给用户的成本策略。

坑 4：演示环境的假数据会骗过自己

有过一次「界面看起来正常、其实读的是内置示例数据」的误判。修法是把回退路径明确禁掉：交付冒烟要真的启动应用、真的点进关键路径、断言界面有内容且没有占位文案。自查要看真实链路，不看截图。

七、边界、风险与下一步#

这类产品最容易被过度承诺，边界需要写清楚：

• 定位是单人/小团队：单机单写者，不做多租户与细粒度权限；多人协作要先解决冲突模型，不是加个登录框；
• 安全边界是「同用户下的门槛」，不是容器隔离：它挡的是浏览器跨站注入、误操作与 Agent 越权调用本机提权接口，挡不住同用户的恶意进程；真正的隔离需要容器执行后端；
• 本地优先的代价是跨设备：默认不依赖云，手机远控要自己搭反向隧道；这是用隐私和成本换来的，不是能力缺失；
• Electron 体积是刻意交换：分发包百兆级，换双击即用与稳定窗口，对目标用户划算。

需要说清楚的是：这些否掉的选项不是永久判决。容器化执行、向量检索、多租户都在「重新考虑的条件」里挂着——比如安全边界要从「门槛」升级成「隔离」，容器执行后端就一定会回来；跨设备需求真起来了，本地优先的代价就得重新算一遍。把否掉的理由和翻案条件一起写下来，比只写结论有用。

下一步优先级也按产品价值排，而不是按技术兴趣：会话线程与工具轨迹（让「它到底做了什么」可读）→ 修改提案 diff 卡（把讨论结论变成可接受/驳回的变更）→ 容器化执行后端（把安全边界从「门槛」升级成「隔离」）→ 多项目模板与验收包复用（让同类项目少配一遍）。

回到最开始：这个产品要证明的不是「AI 能替代人干活」，而是一件事——把一件模糊的事，拆成有角色、有状态、有验收、有回看的工作流。技术只是让这套流程在一个人、一台机器上跑得起来。如果你也在做类似的东西，欢迎交流。

线上演示（mock 模式，无需 Key）：samememory.life/harness，可以直接点开看板与任务详情。项目仍在迭代，欢迎指正。