Multica 愿景解析：把人类与 AI Agent 变成"一个团队"——从 VISION.md 到数据库 Schema 的实现证据

Multica 的 VISION.md 阐述了一个明确的命题：Make humans and AI agents work as one team（让人类与 AI Agent 作为一个团队工作），并把 Multica 定位为"人—Agent 协作的记录与行动系统（system of record and action）"。本文完整梳理这份愿景文档的核心论证——命名由来、"一等队友"设计、工作可见化、历史不随会话消失、以及"人始终负责"的边界——并逐条对照当前仓库的数据库迁移、服务代码与文档站源码，展示这些愿景主张在实现层落地的具体位置与机制，帮助读者理解 Multica 为什么以及怎样成为人与 Agent 的共享工作系统。

一、为什么叫 "Multica"：时间共享（Time-sharing）的回归

VISION.md 开篇给出名字的含义：Multica = Mul tiplexed I nformation and C omputing A gent（复用多路信息/计算代理），并把它放在操作系统史的脉络里：

• Multics 是 1960 年代开创性的操作系统，引入了时间共享（time-sharing）——让多个用户共享一台机器，且各自感觉像是独占；
• Unix 则是对 Multics 的刻意简化：一个用户、一个任务、一种优雅哲学；
• Multica 认为"同样的拐点再次到来"：几十年来软件团队一直是单线程的——一位工程师、一个任务、一次上下文切换；AI Agent 改变了这个等式，Multica 把时间共享带回来，只是这次复用系统的"用户"同时是人类和自主 Agent。

这个隐喻直接对应仓库的技术现实。从源码结构看，"多路复用"不是口号，而是数据模型的基石：

• 在初始迁移 001_init.up.sql 中，issue 表的 assignee_type 与 creator_type 都定义为 CHECK (… IN ('member', 'agent'))，comment 表的 author_type 同样是 ('member', 'agent')——issue 的负责人、创建者、评论者从第一天起就是同构的多态字段，人类成员和 Agent 共用同一套看板、时间线与权限体系，而不是两套平行世界；
• 迁移 042_autopilot.up.sql 建表时也保留了 created_by_type IN ('member', 'agent')，自动化规则的创建者同样允许是 Agent。

VISION.md 中的结论因此可以落到具体实现上："In Multica, agents are first-class teammates"（在 Multica 中，Agent 是一等队友）——它们被分配 issue、汇报进度、提出阻塞、交付代码，与人类同事无异；分配选择器、活动时间线、任务生命周期、运行时基础设施，全部围绕这个理念构建。

二、愿景的痛点：Agent 越多，"收件箱"越多

愿景文档的第二部分 "The vision, made concrete" 先刻画了现状问题：

今天，每加一个 AI Agent，往往就多了一个要管理的收件箱。它的工作活在某个聊天、终端或私有会话里；上下文留在某个人脑子里；决定消失在对话线程中；当工作移交给别人或另一个 Agent 时，团队必须把所有背景重新解释一遍。

Multica 给出的回答是："AI 的承诺不是一个更大的工具集合，而是一个更强的团队"（The promise of AI is not a larger collection of tools. It is a more capable team.）。

围绕这个答案，VISION.md 展开了一条完整的"意图 → 工作 → 评审 → 沉淀"链路，每一环在仓库中都有对应的实现证据：

2.1 工作从人已经在的地方开始

愿景原文：工作可以从人们已经所在的地方开始——一段客户对话、一个 Slack 线程、几句描述"应该改什么"的粗略文字。Agent 把意图转化为可见、结构化的工作，收集相关上下文，并让不确定性显式化。

仓库里的证据链非常清晰：

• Issue 的来源被逐渠道扩展。 issue 表带有 origin_type/origin_id 字段，每次迁移都扩展其取值：060_issue_origin_quick_create.up.sql 加入 quick_create（Agent 快速创建，origin_id 指向 agent_task_queue.id）；111_issue_origin_lark_chat.up.sql 加入 lark_chat（飞书 /issue 命令，origin_id 指向 chat_session.id）；131_issue_origin_slack_chat.up.sql 加入 slack_chat；149_issue_origin_agent_create.up.sql 加入 agent_create（Agent 普通 issue create，镜像 quick_create 的链接语义，使链路顶部的人类 originator 可以被继承解析）。每一个 issue 因此都携带"我从哪里来"的溯源标签；
• 聊天渠道本身是平台无关的。 124_channel_generalization.up.sql 把 Lark 专属的 lark_* 表泛化为带 channel_type 判别列 + JSONB config 的 channel_* 表——这正是 README 中列出的 Slack、Lark、DingTalk、WeCom、Telegram 多渠道接入（channels 文档）共享同一套"在团队已有对话里触发并跟踪 Agent 工作"的机制；
• 触发来源在文档中同样被穷举。 tasks 文档 列出四类触发：把 issue 分配给 Agent 或 Squad、在评论中 @ Agent、在 Chat 中给 Agent 发消息、Autopilot 按计划或外部事件触发——与 VISION.md "work can begin wherever people already are" 的说法一一对应，其中 Autopilot 的 schedule/webhook/api 触发定义在 042_autopilot.up.sql（autopilot_trigger.kind IN ('schedule','webhook','api')，支持 cron 表达式与时区）。

2.2 清晰的任务自动推进，有风险的任务先拉人

VISION.md 的核心原则：

如果任务清晰，Agent 可以自主推进；如果它改变产品行为、引入风险或依赖权衡，正确的决策者会被拉进来，工作才会继续。人设定方向、定义"什么是好的"，并对结果负责。

这一原则的实现证据有两条线：

1. 任务队列与运行时领取机制。 迁移 004_agent_runtime_loop.up.sql 建立了 agent_runtime 表（runtime_mode IN ('local','cloud')、provider、status、last_seen_at，并给 agent 与 agent_task_queue 挂上 runtime_id）——"Agent 的身份"（agent 表）与"执行的机器"（runtime 表）被显式分离，这正对应核心概念文档 concepts.mdx 对 Runtime 的定义："agent is the identity; the runtime is the computer that executes it"。任务的领取、超时与重试规则见 tasks 文档：未领取任务默认 2 小时失败（可用 MULTICA_TASK_QUEUED_TTL 调整）、瞬态故障自动重试、run_only 模式的 Autopilot 不自动重试以避免与下一次调度重叠；
2. 交注意图被结构化保存。 122_task_handoff_note.up.sql 给 agent_task_queue 增加 handoff_note 列：当 issue 被分配/提升到 Agent 或 Squad 时，可以附一条自由文本交接指令；daemon 通过专门的 "assignment handoff" 分支把它渲染进运行的开场 prompt 与 issue_context.md——注释特别强调不是伪造评论或复用 trigger_comment_id。这就是"上下文不再靠口头转述"在 Schema 层的最小实现。

2.3 团队评审的是工作本身，而不是"状态表演"

VISION.md 写道：团队不评审 status theatre，而评审工作本身——计划、文档、实现、diff、预览、测试结果、未决问题。人可以重定向工作、抬高质量标准、批准下一阶段或叫停；Agent 保持日常协调运转，但不隐藏它做了什么、为什么。

仓库中与之对应的机制：

• Issue 状态机自带评审关卡。 001_init.up.sql 中 status 的取值为 backlog / todo / in_progress / in_review / done / blocked / cancelled——in_review 是独立状态，README 也明确 "Work lands in review, not in main. You decide what ships"（工作落到评审而非主干，人来决定什么可以发布）；
• 执行日志让每一次运行可回放。 按 tasks 文档，每个 issue 产生的任务都列在 issue 右侧的 Execution log 中：显示触发来源、执行 Agent、状态与时间，可打开 transcript 查看消息、工具调用与错误输出，可对失败/取消的任务重试，可停止处于 deferred/queued/running 等状态的任务。任务状态集合（deferred → queued → dispatched → waiting_local_directory → running → completed / failed / cancelled）即 VISION.md 所说"不隐藏它做了什么"的最小可验证单元；
• 收件箱只给人、且只报需要人决策的事。 inbox 文档 明确 "Agents don't use the inbox"（Agent 不使用收件箱），收件箱收集的是分配变化、订阅动态、@提及、Agent 运行失败等需要人类关注的事件；Schema 层面，001_init.up.sql 的 inbox_item.severity 三级（action_required / attention / info）就是"被 ping 是因为需要拍板，而不是每一步都打扰"的分层依据，且收件人的 recipient_type 同样区分 member / agent。

2.4 历史不随会话消失：意图、决定、行动、产物保持连接

VISION.md 中最具区分度的一段：

当工作完成时，它的历史不会随会话消失。原始意图、做出的决定、采取的行动、产出的工件、最终结果——它们保持连接。下一个 Agent 不是从零开始。新成员不仅能理解发生了什么，还能理解为什么。

这正是 VISION.md 宣称的目标："become the system of record and action for human-agent work"（成为人—Agent 工作的记录系统与行动系统）。仓库中与之强相关的两块实现：

• 溯源列。 如 2.1 所述，issue 的 origin_type/origin_id 把"这次工作从哪个会话、哪条命令、哪次 Agent 创建而来"固化在数据里；任务侧的 trigger_comment_id、autopilot_run_id、handoff_note 等列则记录"这次运行为何发生"。
• 人类问责归因（Human Attribution）。 迁移 184_agent_task_attribution.up.sql 的设计注释直白对应愿景："Every agent run must be traceable to exactly one accountable human, and that attribution must be EXPLAINABLE"（每次 Agent 运行都必须可追溯到唯一一位负责的人类，且归因必须可解释）。它为 agent_task_queue 增加 originator_source（取值瀑布：direct_human | delegation | comment_source | rule_owner | owner_fallback | backfill | unattributed）、delegated_from_task_id（A @ B 或子 issue 时复制而非链式传递责任，使委派环无害）、retry_of_task_id / rerun_of_task_id（系统重试与人工重跑在报表中严格区分）、rule_version_id、以及 trigger_evidence_kind / trigger_evidence_ref_id（统一证据句柄，可跳转到触发这次运行的那条评论、那次分配或那条规则）。
• 紧随其后的 185_agent_task_accountable_user.up.sql 进一步把"问责人"从 originator_user_id 中拆出为独立的 accountable_user_id，并声明了一条关键设计公理："attribution is on-behalf-of, never blame and never authorization"（归因是"代表某人"，既不是追责，也不参与鉴权）。originator_user_id 继续作为鉴权输入（决定运行在谁的权限下），accountable_user_id 只用于审计、可见性与成本归属；当 originator_user_id 非空时两者相等，只有当运行没有人类授权（如 Autopilot 调度/Webhook）时才允许分歧——此时审计侧仍可降级到规则发布人或 Agent 拥有者。应用层实现见 server/internal/attribution/attribution.go，其包注释同样写明"每次入队运行的负责人类解析契约（MUL-4302）"。

这套设计恰好是 VISION.md 那句 "People set direction and remain accountable. Agents keep the work moving" 的工程化表达：Agent 可以没有人类授权而运行，但每一次运行都能回答"这是在代表谁、为什么、证据是什么"。

2.5 同一模型适用于所有知识工作

VISION.md 最后一段把模型推广出去：同样的"上下文 → 协作 → 评审"模式适用于调研整理、客户简报、内容起草、支持工单推进与客户交付物协调；人类把时间从"在工具间搬运信息、追交接"中解放出来，投入判断力、关系与只有自己能负责的硬决定。同时它明确划界：

Multica 不是失控运转的自主公司。它是人与 Agent 一起从事有意义工作的共享操作系统（the shared operating system for people and agents doing consequential work together）。

从源码结构看，这个"共享操作系统"由一组核心对象构成，concepts.mdx 一页概括：Workspace（自包含协作域）、Issue（工作单元）、Project（组织 issue 并绑定仓库等资源）、Agent（可复用配置：名字、指令、模型、技能、访问、运行时）、Skill（跨 Agent 复用的能力包）、Runtime（执行的机器）、Task（一次具体运行记录）、Squad（由 Agent 领队协调的混合团队）、Chat（不挂在 issue 上的对话，每条消息触发一次运行）、Inbox（注意力路由）。README 中的架构图则给出整体形态：Web / Desktop / iOS 三端 → Next.js 前端 ↔ Go 后端（Chi + WebSocket）↔ PostgreSQL 17，后端经 WebSocket 把任务下发给运行在你自己机器上的 Agent daemon，daemon 再唤起 23 种 Agent CLI 之一。也就是说，"代码不出你的机器"与"多路复用"在架构上是同一个决策的两面。

三、愿景与现状的分界线

VISION.md 结尾专门划了一条诚实的边界：

这份文档描述的是 Multica 正在构建的未来，不是功能清单。关于今天真正可用的能力，请看 README——那里列出的每一项都是活的，且每个功能都链接到其文档。

这一划分值得保留：写产品文档时把"愿景叙事"与"已交付能力"混在一起是最常见的失真来源。Multica 的处理方式是两份文档各司其职——VISION.md（及其中文版 VISION.zh.md）承载理念与方向，README.md 承载"今天就能跑"的事实：23 种 Agent CLI 的运行时分发表（claude、codex、cursor-agent、copilot、kimi、qodercli 等）、五步上手流程、Docker Compose / Helm 自托管方式（详见 SELF_HOSTING.md）、以及 make dev 的开发工作流（前置条件 Node.js 22、pnpm 10.28.2、Go 1.26.6、Docker，贡献流程见 CONTRIBUTING.md）。

四、小结：从"时间共享"到"记录与行动系统"

把 VISION.md 的论证与仓库证据并置，可以得到一条完整的因果链：

愿景主张（VISION.md 原文意译）	仓库中的实现证据
名字致敬 Multics 的时间共享，用户是人类与 Agent 的混合体	001_init.up.sql 中 assignee_type/creator_type/author_type ∈ ('member','agent') 的全局多态设计
Agent 是一等队友：接任务、报进度、提阻塞、交付	issue 状态机含 in_review；comment 类型含 status_change/progress_update；inbox severity 分级
工作从人所在之处开始，意图转为结构化工作	origin_type 逐渠道扩展（quick_create / lark_chat / slack_chat / agent_create）；124_channel_generalization.up.sql 的 channel_* 平台无关模型
人负责方向与结果，Agent 保持运转	184_agent_task_attribution.up.sql、185_agent_task_accountable_user.up.sql 的归因瀑布与"on-behalf-of，永不追责、永不鉴权"公理；attribution.go
历史不随会话消失，下一个 Agent 不从零开始	issue origin_type/origin_id、任务 trigger_evidence_kind/ref_id、122_task_handoff_note.up.sql 的交接备注
评审对象是工作本身，不是状态表演	tasks 文档 的 Execution log / transcript / 重试语义；inbox 文档 "Agent 不用收件箱"
共享操作系统，而非自主公司	concepts.mdx 的核心对象模型；README 架构图中 daemon 常驻用户机器、23 种 CLI 可替换

对读者而言，这份愿景文档的实战价值在于给出了一组可以拿去检验任何"人 + Agent 协作系统"的设计清单：分配、创建、评论、通知是否对人和 Agent 同构？每次运行是否能回答"代表谁、因何触发、证据在哪"？历史是否沉淀为可被下一位成员（或 Agent）直接消费的记录？Multica 的回答是把这些约束写进迁移文件和状态机，而不是写进宣传语——这或许正是"时间共享回归"这句话最具体的含义。