Multica 代码库与 Linear AIG 的对照分析
结论：Multica 的代码实现与 Linear AIG 高度同构——解决的是同一组问题，用的是几乎相同的抽象。但 Linear 在协议层的设计更优雅（delegate/assignee 分离、Activity 不可变、Signal 双向通信）。Multica 的独特价值仅剩 Daemon 本地执行和 Skill 复用系统。
逐条对照
原则 1：Agent 必须表明身份
| Linear AIG | Multica 实现 |
|---|---|
| Agent 有独立视觉标记（badge） | issue.assignee_type = 'agent' + 前端紫色背景 + 机器人图标 |
| Agent 在 user dropdown 中独立分区 | Agent 和 Member 在 assignee picker 中分开展示 |
| Agent 操作在 activity feed 中有标记 | comment.author_type = 'agent'、activity_log.actor_type = 'agent' |
判定：✅ 功能等价。Multica 用 *_type 多态字段区分人和 Agent，Linear 用 OAuth actor=app 区分。底层设计几乎一致。
原则 2：Agent 应原生融入平台
| Linear AIG | Multica 实现 |
|---|---|
| Agent 用和人类相同的操作（创建 issue、评论、改状态） | Agent 通过 daemon → API 创建 comment（type=‘progress_update’）、修改 issue status |
| 不需要特殊界面 | Agent 的操作出现在统一的 timeline view |
判定：✅ 功能等价。两者都让 Agent 通过标准 API 操作平台实体，不需要专门的 Agent 界面。
原则 3：Agent 必须即时反馈
| Linear AIG | Multica 实现 |
|---|---|
10 秒内必须回应 thought，否则标记 unresponsive | 无超时机制 |
| Ephemeral activity（临时状态，被下一条覆盖） | 无等价概念 |
AgentSession 自动从 pending → active | agent.status 手动更新为 ‘working’ |
| Plan API（多步骤进度清单） | 无等价概念 |
判定：⚠️ Multica 缺失。没有即时反馈的强制约束，没有 ephemeral activity，没有 Plan API。用户看到的是 agent.status = 'working' 这个粗粒度状态，看不到 Agent 在想什么、做到哪一步。
代码证据：
server/pkg/db/generated/models.go:30—Agent.Status只有 idle/working/blocked/offline 四种状态server/internal/service/task.go—EnqueueTaskForIssue创建任务后无 10 秒超时检查server/pkg/protocol/events.go—task:progress事件存在但只是通用进度推送，无 thought/action 语义
原则 4：Agent 必须透明内部状态
| Linear AIG | Multica 实现 |
|---|---|
| 5 种语义化 Activity 类型：thought / action / elicitation / response / error | TaskMessage.type：text / tool-use / tool-result（3 种，偏底层） |
| Activity 不可变（时间冻结快照） | ActivityLog 不可变 ✅，但 Comment 可编辑 |
| 用户可检查 reasoning、tool calls、prompts | TaskMessage 流式记录了 Agent 执行步骤 |
| Session 状态可见：thinking / waiting / executing / finished | Agent 只有 idle/working/blocked/offline |
判定：🟡 Multica 有基础但缺乏语义化。
Multica 的 TaskMessage 实际上记录了 Agent 的所有执行步骤（tool-use/tool-result），数据比 Linear 更丰富。但问题是：
- 缺乏语义分层 —
text不区分 thought vs response vs error - 面向调试而非面向用户 — TaskMessage 是 raw agent output，没有为人类阅读优化
- 没有 elicitation — Agent 无法主动向人类提问或请求选择
代码证据：
server/pkg/db/generated/models.go—TaskMessage有Type（text/tool-use/tool-result）、Tool、Content、Input（JSONB）、Output- Linear 的
AgentActivity有 thought/action/elicitation/response/error + body/signal/signalMetadata
原则 5：Agent 必须尊重停止请求
| Linear AIG | Multica 实现 |
|---|---|
stop signal → 立即停止，不做任何额外操作 | CancelTask(taskID) → daemon 收到取消信号 |
| Agent 必须发出最终 response/error 确认已停止 | 任务标记为 ‘cancelled’，无强制确认机制 |
判定：✅ 功能等价，但 Linear 的 Signal 机制更优雅。
Multica 的 daemon 每 5 秒轮询服务器检查任务是否被取消（handleTask 中的 cancellation polling），收到后通过 context cancellation 终止 Agent 进程。这是可工作的，但粗糙——不是即时停止，有最多 5 秒延迟。
代码证据：
server/internal/daemon/daemon.go—handleTask()中有 cancellation polling loopserver/internal/service/task.go—CancelTask()修改任务状态，daemon 下次轮询时发现
原则 6：Agent 不可被问责（delegate ≠ assignee）
| Linear AIG | Multica 实现 |
|---|---|
Agent 设为 delegate，人类保持 assignee | Agent 直接设为 assignee（issue.assignee_type = 'agent'） |
| 责任归属从协议层保证 | 无 delegate 概念，Agent 就是 assignee |
| 清晰的委派模型 | owner_id 只在 Agent 实体上，不在 Issue 上 |
判定：🔴 Multica 缺失关键设计。
这是最大的设计差距。Linear 的 delegate/assignee 分离是 AIG 中最精妙的设计——Agent 做事但人类负责。Multica 让 Agent 直接成为 assignee，意味着：
- 从数据模型上，一个 issue 要么归人、要么归 Agent，没有”人负责、Agent 执行”的中间态
- 当 Agent 完成/失败时，没有自然的”移交回人类”机制
- 审计时无法区分”谁决定让 Agent 做这件事”
代码证据：
server/pkg/db/generated/models.go:164-165—Issue.AssigneeType+Issue.AssigneeID，是直接赋值，不是 delegate- 没有
delegate_id或delegated_by字段
功能对照总表
| AIG 设计要素 | Linear | Multica | 差距 |
|---|---|---|---|
| Agent 身份标记 | ✅ badge + actor type | ✅ type 字段 + UI 标记 | 无 |
| 原生平台操作 | ✅ 标准 API | ✅ 标准 API | 无 |
| 即时反馈 / 10s 超时 | ✅ 强制 | ❌ 无超时 | 大 |
| Ephemeral Activity | ✅ | ❌ | 中 |
| Plan API（进度清单） | ✅ | ❌ | 中 |
| 语义化 Activity 类型 | ✅ 5 种 | 🟡 3 种（偏底层） | 大 |
| Activity 不可变 | ✅ | ✅ ActivityLog 不可变 | 无 |
| Elicitation（Agent 提问） | ✅ | ❌ | 大 |
| Signal 双向通信 | ✅ stop/auth/select | 🟡 仅 cancel（轮询） | 大 |
| delegate ≠ assignee | ✅ | ❌ | 致命 |
| Agent 零成本安装 | ✅ 不计费 | ✅ 自托管免费 | 无（不同模式） |
| promptContext 自动注入 | ✅ | 🟡 daemon 运行时拉取 | 小 |
| OAuth actor=app | ✅ | ❌ PAT/JWT | 中 |
| Repository suggestion | ✅ LLM 推荐 | ❌ | 小 |
Multica 独有的价值（Linear AIG 没有的）
1. Daemon 本地执行
Linear 的 Agent 是外部服务通过 API 操作 Linear。Multica 的 Daemon 在用户本地机器上执行 Agent CLI（claude/codex），代码不离开本机。
意义：对于安全敏感的团队，这是硬需求。但也是之前指出的矛盾——笔记本合盖 Daemon 就停了。
代码位置：server/internal/daemon/daemon.go — 完整的本地执行运行时，包含 semaphore 并发控制、heartbeat、task polling、execution environment 准备。
2. Skill 复用系统
Linear 没有 Skill 概念。Multica 的 Skill 是可打包、可复用的 Agent 指令集，挂载到 Agent 上在执行时注入。
意义：团队级别的 Agent 能力复用。“Deploy to staging” skill 创建一次，所有 Agent 可用。
代码位置：server/internal/handler/skill.go — CRUD；server/internal/daemon/execenv/runtime_config.go — 执行时注入 skill 为 CLAUDE.md。
3. Agent 状态和 Runtime 管理
Linear 不管 Agent 在哪里运行。Multica 有完整的 Runtime 注册、heartbeat 监控、设备信息上报、并发控制。
代码位置：server/internal/daemon/daemon.go — heartbeat 15s 间隔，AgentRuntime 表跟踪在线状态。
4. Session Resume（Claude 会话恢复）
Task 完成后存储 session_id + work_dir，下次同 issue 的任务可以恢复上下文。
代码位置：server/pkg/db/generated/models.go:77-78 — AgentTaskQueue.SessionID + AgentTaskQueue.WorkDir。
设计哲学差异
| 维度 | Linear AIG | Multica |
|---|---|---|
| Agent 在哪 | 外部服务，通过 API 远程操作 | 本地 Daemon，在用户机器上执行 |
| 协议 vs 产品 | 协议提案，任何服务可 follow | 完整产品，自成一体 |
| 抽象层级 | 高层语义（thought/action/elicitation） | 底层执行（tool-use/tool-result） |
| 责任模型 | delegate/assignee 分离 | Agent 直接 assignee |
| 交互方向 | 双向（Agent 可以向人提问） | 单向（人分配任务，Agent 执行汇报） |
| 扩展模型 | OAuth + Integration Directory | 自托管 + 本地 Daemon |
一句话：Linear 设计的是”Agent 如何成为平台的合格居民”，Multica 设计的是”如何在本地高效运行 Agent”。
对 Multica 的建议
如果 Multica 想在 Linear AIG 时代存活，需要做的不是和 Linear 竞争项目管理，而是成为 AIG 协议的最佳本地执行引擎：
- 接入 Linear AIG 协议 — 让 Multica Daemon 可以作为 Linear Agent 的执行后端。用户在 Linear 中 delegate issue 给 Agent，Multica Daemon 在本地执行，通过 AgentSession/AgentActivity API 回报进度
- 补齐 delegate/assignee 分离 — 在 Issue 模型上加
delegate_type+delegate_id - 升级 TaskMessage 为语义化 Activity — 把 text/tool-use/tool-result 映射到 thought/action/response/error
- 加入 Elicitation 机制 — 让 Agent 可以向人类提问并阻塞等待回答
- 保持本地执行 + Skill 系统作为核心差异化 — 这是 Linear 永远不会做的
相关笔记
- 2026-04-01 - Linear AIG - Agent时代的交互协议标准 — AIG 协议全文分析，6 条原则 + 技术架构
- Case - Multica - Agent协作项目管理 — Multica 产品分析 + VC 评估（4.06/10）