企业落地 AI，大致经历了两个阶段。最开始，所有人都知道 AI 很重要，却不知道应该从哪里开始：选模型、买账号、接 API，还是先改流程？
现在，越来越多企业跨过了这一步。员工开始用 AI 写文档、查资料、生成代码，个人效率确实提高了；但回到公司层面，项目还是原来的项目，任务仍散落在聊天窗口、会议和个人提示词里，跨岗位协作、经验复用、质量验收没有同步变快。
问题已经从“怎么让员工用上 AI”，变成了“怎么让 AI 带来组织提效”。
Multica 值得关注，正因为它给出的不是另一个个人 AI 工具，而是一套把人类员工、AI Agent、任务和运行记录放进同一工作系统的解法。
很有意思的地方：这产品一点都不AI
一个 AI Agent 协作产品，核心服务却不依赖直接接入某家模型 API 才能工作——这是 Multica 最克制、也最容易被忽略的设计。
官方对工作原理的概括是：Multica 负责记录和协调工作，连接的电脑负责执行。真正的智能能力来自电脑上已经安装并登录的 Claude Code、Codex、Cursor 等工具；Multica 管理的是 Issue、状态、评论、Agent 配置、Skills 和运行记录。
所以这里的“不依赖 AI API”，不是说系统里没有 AI，而是 Multica 没有把企业锁进某一家模型供应商的服务端调用方式。它更像组织 AI 员工的协作层：底下可以连接不同工具，上面保持统一的任务入口和过程记录。
从个人工具到组织系统，第一步是一块共同看板
在这套真实部署的 Multica 工作区里，Issues 按待规划、待办、进行中、审核中、已完成和已阻塞流转，任务卡片保留负责人和更新时间。人类员工和 AI Agent 面对的是同一张任务卡，而不是各自在不同聊天框里处理同一件事。
这块看板解决的是组织问题：任务从哪里来、现在到哪一步、由谁接手、结果写回哪里、失败后怎么继续，都开始拥有共同语言。个人提效只有进入这条责任链，才可能累积为公司的流程提效。
小队（Squad）：把 Agent 按专业能力组织起来
Squad 在中文里可以理解为“小队”。官方定义里，一个小队由一个 Leader Agent 和若干成员组成，成员既可以是 Agent，也可以是人类。任务分配给小队时，不会把所有成员一起叫醒；Multica 先唤醒 Leader，由它阅读上下文并决定下一步交给谁。
它可以类比公司的专业小组，但不等同于完整组织架构。企业可以把产品、设计、研发、测试分别组织成不同小队；每个小队聚合一组长期稳定的专业能力，具体审批、跨部门责任和治理规则仍需企业自行设计。
一个研发任务，如何在小队里流动
假设产品团队提交一张 Issue：为企业客户增加“项目经营分析仪表盘”。任务卡写清业务目标、页面范围、数据口径、截止时间和验收标准，然后进入研发小队。
研发小队里可以有几名装备不同 Skills 的成员：架构师 Agent 熟悉系统边界和技术决策记录；Java 后端 Agent 熟悉接口规范、数据模型和服务端代码约束；前端 Agent 熟悉组件库、交互规范和浏览器兼容要求。它们不是三个同质化的聊天机器人，而是三种被组织化的专业能力。
- Leader Agent 先读任务。
它判断需要先确认架构和数据口径，而不是立刻让所有成员同时写代码。 - 架构师 Agent 先给出边界。
结果回写 Issue 后，Leader 再决定后端和前端可以并行到什么程度。 - Java 后端 Agent 负责接口与数据。
前端 Agent 根据已确认的契约完成页面和联调。 - 异常重新回到 Leader。
如果接口口径不一致、依赖缺失或任务需要人类决策，Leader 负责继续分派或升级，而不是自己偷偷补完。 - 达到目标后进入审核。
Leader 可以把父任务推进到 in_review；最终 Done 仍交给人类审阅者或既有集成。
同样的方式可以扩展到产品小队、设计小队和测试小队。但这是企业采用 Multica 时可以建立的组织模式，不代表当前产品已经自动完成跨小队流程编排、审批和责任治理。
Leader Agent 的价值，不是更强，而是负责调度
官方设计中，Leader Agent 不承担具体实现。成员回报后，它会再次被触发，阅读新进展，再决定继续分派、升级异常、保持等待，或者在整体目标满足时把父任务推进到审核。
这正是组织提效与个人提效的区别：不是再找一个更全能的 Agent，而是让不同专业能力在明确的任务关系里接续工作，并且让协调过程留下记录。
Skills：把个人经验变成组织可以复用的能力
前端 Agent 的 Skills 可以包含组件使用规范、页面验收清单和兼容性检查；Java 后端 Agent 的 Skills 可以包含接口约束、日志规范、测试命令和发布要求；架构师 Agent 的 Skills 可以包含技术决策模板、风险检查和边界原则。
一次返工如果只留在某个员工的聊天记录里，公司没有真正变强；如果返工原因被整理成 Skill，下一次任务就能直接复用。组织能力因此不再只依附于某个人“很会用 AI”，而是开始变成可以版本化、审查和持续改进的资产。
协调集中，执行仍留在连接的电脑
Issue 分配给 Agent 后，Multica 创建 Task；在线 Runtime 领取任务，调用本地 AI 编程工具，再把进度和结果写回原 Issue。Agent 每次运行都来自明确动作，例如分配 Issue、评论中 @、直接聊天或 Autopilot 触发。
自托管同样分成两部分：Web、API 和 PostgreSQL 构成 Multica 服务；daemon 与 AI 工具运行在连接的电脑上。自托管替换的是 Multica Cloud 这一层，不会自动把模型和执行环境全部搬进服务器。
从组织提效出发，数据应该回答什么
Multica 的用量页提供费用、Token、运行时长、任务数、失败数、排行榜和错误构成。最近 30 天的界面快照显示共 131 个任务，其中失败 15 个。
这些数字只能证明 AI 在运行，不能直接证明公司效率提高了。真正值得追踪的是：一个研发任务跨角色等待了多久、返工了几次、人工介入发生在哪里、验收一次通过率如何、哪些异常已经被新的 Skill 消除。
- 第一阶段：人执行，AI 辅助。
先让 Agent 参与局部工作，结果由人完整复核。 - 第二阶段：AI 执行，人验收。
当 Skills、输入边界和完成定义稳定后，人从具体操作转向结果审核。 - 第三阶段：AI 常态运行，人处理异常。
只有连续数据证明质量稳定，才降低标准环节的人工参与。
这条路成立，但不能跳过四条边界
- Completed 不等于任务完成。
一次运行结束后，Issue 仍可能需要讨论、补充要求或再次触发 Agent。 - Runtime 权限必须隔离。
daemon 下的任务拥有运行用户的文件权限，官方建议使用专用 Unix 用户、容器或虚拟机。 - 小队协作不等于完整组织治理。
审批、分级授权、敏感操作控制、质量抽检和责任追踪仍需补齐。 - 运行数据不等于业务价值。
Token 和任务数之外，还必须定义质量、时效、风险和人工介入等业务指标。
结语：Multica 解的不是“有没有 AI”，而是“AI 如何进入组织”
员工个人使用 AI，解决的是一个人的效率；让任务进入共同看板，让专业 Agent 组成小队，让 Leader Agent 负责调度，让返工沉淀为 Skills，解决的才是组织怎样逐步获得 AI 能力。
Multica 现在仍处于早期，治理与管控远未完备。但它给出了一个很好的起步方向：不急着把所有工作交给 AI，而是先让人类员工和 AI 员工在同一系统中协作、留痕和复盘，再依据真实数据逐步扩大 AI 的职责边界。
