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