最近在研究 Multica，一个把 Agent 塞进任务板的协作平台。用了一段时间，我觉得有点意思，但终究只是过渡形态，不是终局。
它解决了一个真实问题，但解决方式是把团队装进平台的固定流程里。7 个预设状态、固定的 issue 模型、被动的看板，团队需要适应这套结构才能用起来。
但真实工作的协作比这复杂多了。一个招投标团队和一个软件开发团队，工作流的结构完全不同，甚至在同一个团队里，不同类型的任务也有不同的阶段定义。让团队去适应平台的工作流，不对！
Multica 做了什么？
Multica 是一个任务协作平台，核心设计是把 Agent 当一等公民：issue 的 assignee 可以是人，也可以是 Agent。
Agent 能被分配任务、在评论里回复、更新状态、甚至担任项目负责人。状态流转宽松，7 个固定状态之间可以任意跳转，不强加线性工作流。
Agent 执行任务时跑在用户本地的守护进程上，调用 Claude Code、Codex 等 AI 编程工具，API 密钥和代码目录都留在本地。
这套设计解决了一个真实问题：人和 Agent 终于在同一个工作区里了。你可以像给同事派活一样给 Agent 派活，Agent 干完了在评论里汇报，和人类同事的工作方式几乎没有区别。
但用着用着，问题就出来了。
Multica 没解决的问题
阶段归平台管，不该归平台管
Multica 的 issue 有 7 个固定状态：backlog、todo、in_progress、in_review、done、blocked、cancelled。一个 bug 修复和一次标书撰写，生命周期完全不同，但被迫穿同一件衣服。
软件开发里，PRD 走"设计→审查"两个阶段就够了，Feature 开发走"需求设计→API设计→开发计划→开发实现→E2E测试"五个阶段。招投标里走的是"文件分析→方案制定→标书编写→审核校验→得分比较"。这些阶段的数量、名称、内部状态各不相同，固定状态根本覆盖不了。
门控藏在暗处
Multica 里人类可以随时介入：手动改状态、评论里发指令、ReRun 任务。但这些介入点散落在各处，没有声明机制。你需要记住"这个项目的审查环节我要盯着"，这个知识存在于你的脑子里，不存在于系统里。
一个五人的招投标团队，张经理需要审查方案，王法务需要审核商务条款，赵商务需要确认报价。每个人该在什么时候介入、介入后做什么、决策结果怎么传递，全靠人手动操作和口头约定。
灵活是有了，约束也跟着没了。
回退靠手动模拟
Multica 的状态可以任意跳转，所以技术上你可以把 in_review 的 issue 手动改回 todo 来模拟打回。但系统不知道这是一次"审核打回"，它只看到一个状态变更。没有打回原因的传递，没有回退目标的记录，Agent 拿不到结构化的反馈。
招投标的审核环节打回是家常便饭。法务发现条款不一致，打回给商务改；技术标审查发现工期安排有矛盾，打回给技术团队重新编排。每次打回都要人工改状态、手动通知、口述原因，协作成本很高。
没有协作智能
但最要命的是，Multica 是一个被动看板：你不开它就不动。Agent 完成了任务，你打开平台才能看到。某个门控点被触发三天了没人处理，平台不会提醒你。跨人的工作依赖关系，比如李总工的方案要等张经理的文件分析，平台不知道也不通知。
底层逻辑
怎么改？先说清楚三条底线。
工作流围着你的团队转，别反过来。工作流的结构都要可配。阶段、状态、门控、文件路径，全部由用户按任务类型自定义。用户已有的本地进度管理方式通过映射配置接入，不用改工作习惯。
人决定哪些决策重要。门控是显式的可选约束。框架提供默认门控，用户可以保留、移除或追加。没有被门控拦住的状态转换，Agent 自己往前推就行。
编排和执行分开。平台管"什么时候轮到谁动"，Agent 的能力边界是 Agent 自己的事。协作指令由平台注入，能力指令由本地管理，通过标准文件接口对接。
五层框架 + 协作 Agent
第一层：阶段模板层
用户按任务类型自定义阶段。每个阶段模板包含：阶段列表、每个阶段的状态集合（默认提供"未开始/执行中/已完成"，可覆盖）、每个阶段的输入/输出文件声明。
任务类型：投标
阶段 1：招标文件分析（输入：招标公告.pdf，输出：分析报告.md）
阶段 2：投标方案制定（输入：分析报告.md，输出：投标方案.md）
阶段 3：投标标书编写（输入：投标方案.md，输出：技术标.md + 商务标.md）
阶段 4：审核校验（输入：技术标.md + 商务标.md，输出：审核意见.md）
阶段 5：得分点比较（输入：全部产出物，输出：得分分析.md）第二层：状态转换层
定义阶段之间的前进规则和后退规则。底层是自由跳转（Multica 模式），门控是可选的约束。任何状态都可以跳到任何状态，但挂了门控的转换需要人类确认。
回退作为一等公民：任何"已完成"的阶段都可以被人类打回，打回到哪个阶段由打回者当场决定。Agent 只需要知道"这个阶段被打回了，当前状态变成执行中"，然后继续工作。
第三层：门控层
两级门控。默认门控挂在高概率需要审查的转换点上（比如每个阶段的"已完成"），用户可以在模板级别关闭。自定义门控由用户在任何状态转换上手动追加。
门控触发后，平台传递两样东西给 Agent：状态转换的决策（通过/打回/打回并指定回退阶段），以及可选的附加信息（人类附带的任何内容）。人怎么介入是人的事，框架不管。
第四层：任务依赖层
定义跨任务的依赖关系。项目启动时批量创建所有任务，指定负责人和截止日期，声明依赖关系。协作 Agent 基于依赖关系做调度：前置任务没完成导致后续任务无法开始时通知前置负责人，快到截止日期但进度滞后时提前预警。
第五层：本地流程映射层
用户已有的进度管理文件（YAML、Markdown、任何格式）通过映射配置接入平台。Agent 帮忙生成映射配置：读一遍用户本地的进度文件，理解结构，自动生成"本地文件的哪个字段对应平台的哪个阶段"的映射。
用户在本地改文件、commit、push，平台通过 Git 变更自动感知并更新阶段状态。不用切换到平台操作。
上下文传递：双线设计
文件上下文通过 Git 传递。阶段模板声明了每个阶段的输入/输出文件路径，Agent 进入阶段时知道该读什么，完成时知道该写什么。每个阶段完成时 commit 一次，Git 历史就是项目进度日志。
协作上下文通过平台的接口协议传递。阶段状态、门控决策、反馈意见这些不适合塞进 Git 的信息，通过平台注入到 Agent 的工作环境中。
两条线在 Agent 执行时合并：Agent 同时读到文件上下文和协作上下文，拼成完整的工作环境。
协作 Agent：看板和助手的区别
五层框架解决了编排问题，但一个纯被动的编排系统和 Jira 没有本质区别。区别在哪？协作 Agent。
协作 Agent 是一个独立的服务，和用户本地的干活 Agent（Claude Code、OpenCode）是不同的东西。本地 Agent 看到的是单点（当前任务、当前阶段），协作 Agent 看到的是全局（所有任务、所有人的状态）。
它干三件事。
第一件事，主动推送。门控被触发时通知对应的负责人，前置阶段完成时通知下游，并行任务的产出物更新时通知相关人。走飞书、钉钉、邮件还是平台内通知，用户自己配。
第二件事，智能推荐。基于阶段模板和历史数据，推荐下一步行动。完成招标文件分析后推荐参考同类项目模板，完成需求设计后推荐对应的 Skill。
第三件事，瓶颈预警。发现某个阶段连续多天无进展时主动提醒负责人和项目经理，发现某个负责人同时背负多个任务且截止日期临近时建议调整分配，发现跨人的接口设计不一致时主动提醒对齐。
调度能力分两层：基础定时器做确定性的周期任务（每天推送进度摘要、每周跑代码扫描），智能调度由协作 Agent 基于上下文判断要不要触发、触发什么、通知谁。用户可选其一或叠加。
平台保持无状态（事件总线 + 消息通道），智能集中在协作 Agent 里，本地 Agent 保持专注。
场景一：招投标
张经理是投标负责人，团队成员有李总工（技术）、王法务（法务）、赵商务（商务报价）。
张经理收到招标公告后启动投标任务，选择"投标"阶段模板，一次性邀请团队成员，每个阶段指定负责人：文件分析由张经理负责，方案制定由李总工负责，标书编写由张经理和李总工共同承担，审核校验由王法务和赵商务分别负责，得分点比较由张经理负责。门控做了调整：方案制定完成后需要张经理审批，审核校验的法务和技术审核并行，两个都通过才能进入得分比较。
阶段 1，张经理上传招标公告，Agent 生成分析报告。门控触发，张经理审查通过。协作 Agent 自动通知李总工可以开始方案制定了。
阶段 2，李总工的 Agent 生成两套技术方案，李总工倾向 B 方案但标注了工期风险顾虑。门控触发，协作 Agent 给张经理推送审查通知，并提示"李总工在方案里标注了技术路线的选择顾虑"。张经理和李总工在评论区讨论了 3 个来回，最终选 B 方案。协作 Agent 把决策传递给李总工的 Agent，李总工补充工期风险说明后方案定稿。
阶段 3，张经理把标书拆成技术标和商务标，李总工和赵商务并行编写。李总工写到"项目团队"章节时发现需要人员资质材料，给赵商务发消息。赵商务上传材料后，协作 Agent 自动通知李总工继续推进。张经理每天收到协作 Agent 的并行进度摘要。
阶段 4，并行审核。王法务发现商务标的违约金条款和招标文件不一致，打回给赵商务。李总工自审技术标后提交，张经理发现施工组织设计的时间节点和方案风险说明有冲突，打回指定回退到阶段 3。两个审核都通过后，协作 Agent 自动推进到阶段 5。
阶段 5，Agent 逐项对比评分标准，协作 Agent 发现"类似项目业绩"项可能失分，建议赵商务补充材料。最终估算得分覆盖评分标准的 88%，投标文件提交。
全程张经理没有主动在平台上操作过一次，所有通知和决策都通过协作 Agent 的推送和门控机制完成。
场景二：软件开发
锅总是技术总监，管理一个 SaaS 订单管理系统。团队有小李（后端）、小陈（前端）、老王（测试）。
项目启动时，锅总一次性创建所有任务并排好截止日期：
PRD 设计 锅总 第 3 天
架构设计 锅总 第 5 天
订单列表 小李+小陈 第 15 天
订单详情 小李 第 18 天
订单状态流转 小李+老王 第 20 天
E2E 集成测试 老王 第 22 天依赖关系：所有 Feature 依赖 PRD 和架构设计，集成测试依赖所有 Feature。
锅总已经有一套本地的 Progress YAML 管理体系，Agent 自动生成了映射配置。从此以后，锅总在本地改 progress.yaml，commit 并 push，平台自动同步阶段状态。
门控也做了调整：需求设计和 API 设计阶段必须锅总审批（出错代价最高），开发计划和开发实现不需要门控（Agent 自主推进），E2E 测试完成后老王审批。
PRD 和架构设计完成后，协作 Agent 通知三个 Feature 的负责人可以启动了。
订单列表进入 API 设计阶段。小李的 Agent 生成 API 文档，其中分页参数的设计发生了变更。commit 后，协作 Agent 检测到 API 文档变更，主动通知小陈："订单列表的 API 分页参数从 page/size 改成了 cursor/limit，你的前端代码里有调用需要更新。"
开发实现阶段，小李和小陈并行开发。协作 Agent 每天推送进度摘要。第三天，协作 Agent 发现小李连续 2 天没有新 commit，给锅总推送风险提醒。锅总确认是第三方 SDK 兼容问题，在评论区更新了设计备注，协作 Agent 同步给小李和小陈。
E2E 测试阶段，老王的 Agent 跑出 2 个失败用例。老王打回，协作 Agent 把反馈分别推给对应的开发者：小李负责导出超时问题，小陈负责排序空数据异常。两人各自修复后，老王重跑测试通过。
订单列表完成后，协作 Agent 给小李推送下一个 Feature 的上下文，并提醒保持字段命名一致性。小李做订单详情时，协作 Agent 发现一个字段命名和订单列表不统一，主动提醒修正。
3 个 Feature 全部通过后，协作 Agent 给锅总发汇总：项目耗时、各阶段平均耗时、测试通过率、打回最多的阶段、改进建议。完整的项目时间线自动记录，没有人需要主动填写任何日志。
所以我们需要什么
AI 不可能永远执行工作，这是事情的性质决定的。
真实项目里，决策点散落在流程各处。张经理要审方案，锅总要批需求设计，王法务要看条款。这些决策点没有规律到可以自动化，也没有少到可以忽略。人必须在循环里，和 AI 一起走完整条链路。
但人的角色变了。生成报告、写代码、跑测试、填模板，执行全交给 AI。人只管一件事：保证 AI 的工作不偏离。方向对不对，质量够不够，边界条件有没有漏，这些判断至少目前只有人能做。
问题来了。十个并行任务，你怎么知道每个做到哪了？哪个卡住了？哪个门控等你两天了？
挨个问，问一圈半小时，信息还是过时的。开站会，十五分钟同步完，同步的是昨天的状态，今天的变故没人知道。
所以需要一个平台，所有任务的状态摊在面上。哪个任务在哪个阶段，卡在哪里，等谁决策，有没有超期，一眼看到。人不用去找信息，信息自己找上门。
看板是人去翻的，协作平台是来找你的。门控触发了通知你，进度滞后了提醒你，接口不一致了警告你。人做的事就两件：看一眼全景，做判断。剩下的，AI 来。