真实工作的协作比这复杂多了。一个招投标团队和一个软件开发团队工作流的结构完全不同甚至在同一个团队里不同类型的任务也有不同的阶段定义。让团队去适应平台的工作流不对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 是一个独立的服务和用户本地的干活 AgentClaude 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。阶段 5Agent 逐项对比评分标准协作 Agent 发现类似项目业绩项可能失分建议赵商务补充材料。最终估算得分覆盖评分标准的 88%投标文件提交。全程张经理没有主动在平台上操作过一次所有通知和决策都通过协作 Agent 的推送和门控机制完成。场景二软件开发锅总是技术总监管理一个 SaaS 订单管理系统。团队有小李后端、小陈前端、老王测试。项目启动时锅总一次性创建所有任务并排好截止日期PRD 设计 锅总 第 3 天 架构设计 锅总 第 5 天 订单列表 小李小陈 第 15 天 订单详情 小李 第 18 天 订单状态流转 小李老王 第 20 天 E2E 集成测试 老王 第 22 天依赖关系所有 Feature 依赖 PRD 和架构设计集成测试依赖所有 Feature。锅总已经有一套本地的 Progress YAML 管理体系Agent 自动生成了映射配置。从此以后锅总在本地改 progress.yamlcommit 并 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 的工作不偏离。方向对不对质量够不够边界条件有没有漏这些判断至少目前只有人能做。问题来了。十个并行任务你怎么知道每个做到哪了哪个卡住了哪个门控等你两天了
从Multica看人与人与Agent的协作平台
真实工作的协作比这复杂多了。一个招投标团队和一个软件开发团队工作流的结构完全不同甚至在同一个团队里不同类型的任务也有不同的阶段定义。让团队去适应平台的工作流不对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 是一个独立的服务和用户本地的干活 AgentClaude 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。阶段 5Agent 逐项对比评分标准协作 Agent 发现类似项目业绩项可能失分建议赵商务补充材料。最终估算得分覆盖评分标准的 88%投标文件提交。全程张经理没有主动在平台上操作过一次所有通知和决策都通过协作 Agent 的推送和门控机制完成。场景二软件开发锅总是技术总监管理一个 SaaS 订单管理系统。团队有小李后端、小陈前端、老王测试。项目启动时锅总一次性创建所有任务并排好截止日期PRD 设计 锅总 第 3 天 架构设计 锅总 第 5 天 订单列表 小李小陈 第 15 天 订单详情 小李 第 18 天 订单状态流转 小李老王 第 20 天 E2E 集成测试 老王 第 22 天依赖关系所有 Feature 依赖 PRD 和架构设计集成测试依赖所有 Feature。锅总已经有一套本地的 Progress YAML 管理体系Agent 自动生成了映射配置。从此以后锅总在本地改 progress.yamlcommit 并 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 的工作不偏离。方向对不对质量够不够边界条件有没有漏这些判断至少目前只有人能做。问题来了。十个并行任务你怎么知道每个做到哪了哪个卡住了哪个门控等你两天了
