Multica：让 AI Agent 成为一等公民
AI 写代码的能力已不再是问题，现在的 Agent 可以读代码、写实现、跑测试、修 Bug，甚至直接开 PR。真正的问题在于：如何同时协调好多个 Agent？
单个 Agent 还能盯着，两个 Agent 还能手动协调，五个、十个便难以应对。任务拆分依赖记忆，进度靠切换终端，冲突靠肉眼发现。问题不在于工具本身不好，而是工具从一开始就不是为这个场景设计的。
当 Agent 多起来之后
给三个 Agent 分配了用户模块、订单模块和支付模块的开发任务。用户模块改了接口签名，订单模块的 Agent 并不知情，继续按旧接口在写。等到 review 时发现两边对不上，已经全是错的。
这是必然会发生的局面。Agent 之间没有共享的上下文，每个都在自己的小世界里工作，人成了唯一的信息中转站。打开五个终端窗口各跑一个 Agent，时不时切过去扫一眼——Agent 多了之后，大部分时间不是在思考问题，而是在做监控。
代码合并时问题更突出。编译器能发现语法错误，发现不了逻辑冲突。两个 Agent 各自实现了一套错误处理逻辑，调用约定不一致，只能靠人去读懂两边在做什么然后手动调和。Agent 越多，这种隐性集成成本越高。
根源在于现有的项目管理工具默认执行者是人。Agent 在这些工具里只是一个名字，没有身份、没有状态、没有协作能力。
为什么现有产品不够用
GitHub Projects 很好用，但是面向人设计的。Issue 分配给用户，Project 看板追踪人的任务，Actions 响应人的操作，整个数据模型里没有 Agent 的位置。
硬要把 Agent 塞进去，只能把它当成人来用——给 Agent 建个账号，让它在评论里汇报进度，手动把执行状态更新到 Issue 里。能跑，但别扭。别扭在哪里？Agent 调用了哪些工具、遇到什么错误、尝试了几种方案，全在它自己的会话里，GitHub 看不到。只能看到最终结果，出了问题没法复盘 Agent 是如何走到这一步的。
Claude Code 里有 Agent Teams，能让多个 Agent 互相通信、认领任务。这比 GitHub Projects 进了一步，但会话断了一切都丢了——状态存在当前会话里，关掉 IDE 或者超时，谁在做什么、协调过什么，全没了。而且它假设的场景是一个人加 N 个 Agent，没有团队视图，没有权限管理，多个人协作管理 Agent 这件事根本不在设计范围内。
更深层的问题是过程仍然是黑盒。Agent 之间的任务分配逻辑、决策路径、失败原因，没有结构化记录。想知道 Agent A 为什么放弃了方案 X 选择方案 Y，只能去翻会话日志。
Multica 做了什么
Multica 的思路很直接：把 Agent 当作真正的团队成员，不只是人的工具。
听起来朴素，但意味着数据模型、交互方式、部署架构全部要重新考虑。
Agent 拥有独立身份。 在 Multica 里，Agent 和人一样有自己的身份、能力描述、工作记录。Issue 可以分配给 Agent，Agent 可以认领 Issue，在 Issue 下面评论汇报进度。人和 Agent 可以在同一个工作流里协作，通过同样的机制沟通和追踪，Agent 产生的代码、文档、测试报告被当作工程资产沉淀下来，与人的产出同等对待。
Issue 记录的是过程，不只是待办。 传统项目管理的 Issue 记录要做什么，Multica 的 Issue 记录这个过程里发生了什么——需求描述、讨论过程、决策理由、失败的尝试、上下文快照都在里面。Agent 执行任务时把思考过程、工具调用记录、错误信息都写进 Issue 或关联文档里。
这样做的好处是 Agent 中断后可以从 Issue 里恢复现场，不只是接着上次的代码写，而是接着上次的思路想，知道之前试过什么、为什么放弃。这些记录还会沉淀为团队知识，下一个类似任务启动时，新的 Agent 可以读到上次的经验。
实时掌握所有 Agent 的状态。 Multica 有一个通过 WebSocket 推送状态变化的实时面板，哪个 Agent 在执行、哪个遇到阻塞、哪个完成了工作，全部实时显示。每次状态变更和 Agent 行动都有日志，形成完整的可观测性链条。出了问题可以回溯，想优化流程可以分析数据。
可以部署在内网。 Multica 是开源的，用 Go + PostgreSQL，可以部署在自己的环境里。架构上把 AI 能力和项目管理能力分开了——Multica 不管你用的是什么模型、什么 Agent 运行时，它只负责编排、追踪和沉淀。Agent 可以用 Claude Code，可以用 CodeBuddy Code，可以用内网部署的开源模型，Multica 管的是这些 Agent 之间的协作。
和 Agentic Engineering 放在一起用
Multica 本身是协作平台，和 Agentic Engineering 体系结合之后效果不只是叠加。
Agentic Engineering 提供的是让 Agent 可靠写代码的方法论：结构化的上下文管理、分阶段交付、门禁机制、知识沉淀规范。Multica 提供的是让这套方法论在多 Agent 场景下可操作的基础设施。
单 Agent 场景下，流程靠 Prompt 和规则约束。多 Agent 场景下，Multica 的 Issue 结构可以把流程固化下来：每个阶段是一个 Issue 或子 Issue，状态流转和门禁绑定，不通过评审就转不到下一阶段。
知识沉淀上，Agentic Engineering 要求每次任务产生的经验写进 context/ 下的文档里。Multica 可以记录哪些上下文被哪些任务用了、效果如何，用数据来指导上下文管理的优化。可观测性上，Multica 记录的 Token 消耗、执行时长、失败原因、人工干预记录，为分析 Agent 为什么失败、哪个环节最容易出错提供了数据基础。
还不够好的地方
人仍然是瓶颈。任务从哪里来、怎么拆分、优先级怎么定、出现分歧谁拍板，现在还需要人参与。能同时管理的 Agent 数量，上限取决于人的响应速度，而非工具有多少功能。
Agent 之间的协调还很初级，主要是事件驱动：一个 Agent 完成任务后通知其他相关方。两个 Agent 计划修改同一个文件，提前发现并协商，现在还做不到。
质量审查需要分层。全靠人审查不够用，全靠自动化靠不住。现在在探索三层模型：自动检查管格式和基本错误，AI 辅助审查管代码质量和逻辑一致性，人来管架构决策和安全敏感的部分。
任务拆分还不能完全自动化。把一个大需求拆成多个可并行执行的子任务，需要理解需求、代码结构和依赖关系，现在的模型能做，但不够可靠，需要更多项目上下文来辅助。
成本也需要管理。并行意味着更多 Token 消耗，但不是所有任务都需要最强的模型。需要有依据地决定这个任务用什么模型、这个 Agent 跑多久、什么时候该人工介入而不是让 Agent 继续试。