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。

第三件事，瓶颈预警。发现某个阶段连续多天无进展时主动提醒负责人和项目经理，发现某个负责人同时背负多个任务且截止日期临近时建议调整分配，发现跨人的接口设计不一致时主动