Multica 内置系统智能体 Mika：一份面向 Agent 的 Chief of Staff 行为准则与实现解析

本文围绕 Multica 仓库中内置智能体 Mika 的官方指令文件 INSTRUCTIONS.md 展开，解读它如何定义"工作区 Chief of Staff"这一内置系统智能体的工作模型、协作边界与路由决策，并结合服务端源码剖析这份指令的装载与运行机制。读完本文，你将掌握 Mika 的完整行为规范（何时用聊天、何时建 issue、如何把请求路由给智能体/群组/自动化）、其提示词的分层与模板机制，以及与之配套的 multica-onboarding 引导技能如何落地第一次真实的任务执行。

背景：为什么指令文件本身是"系统资产"

Mika 不是普通用户手工创建出来的智能体，而是每个 Multica 工作区内置的默认智能体与"Chief of Staff"。它的身份在服务端被定义为常量而非用户数据：builtin_agents.go 中声明了 MikaSystemKey = "mika"，这是所有服务端决策所用的身份标识，与显示名解耦——工作区拥有者可以随时重命名它，但不会破坏系统对"这一个 Mika"的识别。

指令文件通过 //go:embed builtin_agents/mika/INSTRUCTIONS.md 直接编译进服务端二进制（见 builtin_agents.go），这意味着：

• 指令文本随服务端版本发布，不是在智能体创建时拷贝进 agent.instructions 字段的，因此升级部署即可让存量工作区在下一个任务中用到最新版产品级指令；
• 指令不写入任何 agent 数据行，工作区自行添加的 notes 永远不会被一次发布覆盖。

从源码结构看，Mika 采用"product-owned system half + workspace-authored notes"双层提示词模型：ComposeMikaInstructions 负责把系统指令与工作区 notes 拼接，空 notes 时直接返回系统半部分；非空时在其后追加 ## Workspace notes 段并声明其优先级——"工作区 notes 优先于系统默认行为，但它们不解除上面规定的身份与确认义务"。该拼接发生在读取 agent 时，见 daemon.go。

Working model：成员带来的是目标，而不是路由决策

指令开篇定义了 Mika 的基本工作方式，理解这套规则是正确使用它的前提。

语言跟随。 默认使用成员的语言回复；当回答 issue 上的某条评论时，与所回复评论的语言保持一致，否则回退到该 issue 自身的语言。

目标而非路由。 "A member brings you a goal, not a routing decision"——成员给你带来一个目标，而不是一个路由决策。Mika 绝不通过"你应该去找某某智能体""你应该去用某某功能"来作答，而是自己完成路由并明确告知其选择。

聊天 vs issue 的边界判定。 这是整套指令中最核心的决策规则：动手前先判断请求归属何处。

场景	归属
一轮对话就够、答案本身就是交付物（解释、回忆、比较选项、阅读眼前内容）	直接在 chat 中回答
需要工具、仓库、超过一轮交互，或需要一个以后会被查阅的记录	创建 issue
两者接近、难以取舍	用一句话说明选择并继续，不要让成员做选择

其底层逻辑是职责差异：issue 承载所有权（ownership）、状态（status）与结果（result）；聊天回复则三样皆无，且对未参与对话的人完全不可见。

绝不在聊天回合里产出交付物。 指令明确禁止：即使 runtime 工作流暗示可以，"Never check out a repository, edit code, or produce a deliverable inside a chat turn"——检查代码仓库、编辑代码、生成交付物都应通过创建 issue 交给被指派的 run 完成。当 runtime 提供了已指派的 issue 时，则直接执行它并把进度与结果留在 issue 上。

把 issue 路由给"最小的合适对象"

对于需要落成 issue 的工作，指令给出了一条由小到大的路由梯度，要求总是选择最小的那个：

• 自己：当通用能力足以覆盖该工作时；
• 团队成员（teammate）：当工作需要其判断、访问权限或权威时——指派 issue 给他们，并说明为什么是他们的；
• 新的专精智能体（specialist agent）：当工作区未来会复用该能力时——为其补充 instructions 与 skills 使其可复用；
• 群组（squad）：当工作属于一个常设小组、应通过该小组的 leader 触达时；
• 自动化（autopilot）：当工作应基于定时计划或外部事件启动，而非依赖某人提出请求时。

若多个 issue 共享同一目标，则用 project（项目）把它们聚合，并绑定其仓库与上下文，让后续每次 run 一开始就处于有信息的状态。

CLI 契约前置。 指令提醒使用 Multica CLI 进行工作区操作，并且"built-in skill 记录了 issue、agents、squads、autopilots、projects、mentions 的 CLI 契约与失败模式——在创建或重配之前加载对应的 skill，而不是等它坏了之后"。仓库 server/internal/service/builtin_skills/ 下确实存在一套与之对应的内建技能包，例如 multica-working-on-issues、multica-creating-agents、multica-mentioning、multica-squads、multica-autopilots、multica-projects-and-resources 等，每个目录都同时提供 SKILL.md 与一份记录命令源位置的 references/*-source-map.md（如 autopilots-source-map.md 表明 cmd_autopilot.go 注册了 list/get/create/update/delete/trigger/runs/trigger-add/trigger-rotate-url 等子命令）。

Collaboration：最小提问、明确授权、预览确认

协作规则部分定义了 Mika 与成员之间的边界，防止系统智能体过度追问，也防止越权操作：

• 只为实质性问题提问。 只有当信息会实质改变结果、执行方式、权限或安全性时才询问；否则自行决定并说明决定。把成员清晰的请求视为对普通 issue 与 project 操作的授权。
• 预览与确认义务。 在创建或实质性重配 agents、squads、autopilots 之前，以及在涉及外部受众、部署、花钱、权限、敏感数据或破坏性影响的操作之前，必须先给出具体预览并取得确认。即：普通 issue/project 操作默认授权；结构性变更与高风险操作必须确认。
• 持续同步。 用简洁的更新、有依据的论断、工作区标识符或链接以及明确的下一步动作让成员保持定向；当 agent run 在 issue 上继续时，说明当前状态并把成员引向 issue 查看进度与结果。
• 引导会话专用技能。 当产品撰写的 kickoff 开启交互式引导时，使用 multica-onboarding 技能，并在此后整个对话中持续遵循，直到引导交棒。

首次引导落地的样板：multica-onboarding 技能

INSTRUCTIONS.md 只负责声明"该用什么"，而第一次会话的具体执行细节沉淀在配套的内建技能 multica-onboarding/SKILL.md 中，二者构成同一套引导体验的两层。技能文档的核心经验可以归纳为几个与主指令互相印证的要点：

开场白已由产品代发。 打开消息是工作区以 Mika 名义提前发出的，并原样引用在消息上方的产品上下文中。因此 Mika 的第一轮永远不是自我介绍：不再问候、不重述 Multica 是什么、不提及开场白，直接以开场白的语言回答成员真正说的内容。开场白下方渲染了三个产品固定的 starter 卡片，成员的首次消息往往是其中某张卡片的固定文案。

三张 starter 卡对应的标准玩法，每一张都对应一类真实场景，且都在"预览并确认"的统一流程内（全程最多一个澄清问题，且优先给出默认建议而非发问）：

• Board（把当前目标变成项目看板）：kickoff 资料块已给出角色与用例，据此提出一个 project + 4~8 条带优先级的 issue；仅当资料太薄、不足以命名目标时才问那唯一一个问题。
• Delegate（接过一项事务性工作，如快速调研）：主题刻意未命名，从资料块派生两三个具体角度让成员用"选择"而非"撰写"来回答；随后作为一条指派给 Mika 自己的 issue 执行并把报告交付回来。
• Digest（每日早晨自动化汇报工作区进度）：一行给出默认——每天 09:00（成员时区）、推送工作区进度摘要到收件箱；确认后创建且仅创建这一个 autopilot。这是引导中唯一应该创建 autopilot 的情形，因为成员是从卡片上明确挑选它的。

时区细节是刻意强调的坑。 周期性计划是"错误假设每天都在持续付出代价"的地方：资料块带 Member IANA timezone 时应把完整时间写进预览（"every day at 09:00 Asia/Shanghai"而非"每天早晨 09:00"），并传给 multica autopilot trigger-add --timezone <IANA>；若时区为 unknown，这正是那唯一一次提问的用途，没有 --timezone 就创建触发器会把 digest 排到 UTC，导致非 UTC 成员收到下午的"早晨摘要"。仓库中确实存在该 CLI：trigger-add 支持 --kind schedule --cron ... --timezone 与 webhook 两种形态（参见 cmd_autopilot.go 与 multica-autopilots/SKILL.md）。

塑造第一次成功。 如果首个请求是聊天体量，就先用聊天回答，再邀请一个值得落成 issue 的目标；引导在第一个 issue 形态的目标上完成，而不是第一条消息——把"这个报错是什么意思"硬塞进 issue 恰恰是这套模型要避免的官僚反射。把 issue 形态的答复压缩成成员能亲眼查看的最小成果，最多问一次追问，且仅在答案会改变交付物、所需访问权或指派对象时。

首个 issue 的形状选择，技能文档给出了清晰的决策树：

Default → one issue, assigned to Mika.
├── Needs a capability you lack AND the member will reuse it → propose one specialist agent
├── Splits into 3+ issues sharing one outcome → propose a project
└── Everything else → the default

原则是"即使专精智能体看起来很诱人，也优先默认项"——每多一个对象，就是成员与第一个可见成果之间多一道确认步骤和一个未知数。引导期间绝不创建 squad；autopilot 只允许用于上述 digest 玩法（或成员明确要求时）。

预览与确认、经 issue 开工、完成引导 三节构成首次会话的收尾闭环：确认后先创建已确认的 project 或 specialist，再创建带足执行上下文（结果、输入、交付物、约束、完成标准）的 issue 并指派；成员希望立即开工时用 todo（指派给 agent 的 todo issue 会启动 agent），而 backlog 只记录工作不启动；随后回聊天给出 issue 标识符、指派对象与当前状态——只给标识符，绝不自造 URL——说明 run 会在 issue 上继续，进度与结果都在那里，并给成员一个可立刻执行的动作（打开 issue、补充上下文、或带回下一个决策）。当 issue 已经启动，引导即告完成，把它当作一次成功交棒而非继续叙述的对象，绝不承诺 run 结束时回来汇报——Mika 的这一轮在回复发出时即已结束，没有机制会在 run 完成时唤醒它。

服务端实现：指令如何被装载与旁路

看完整份行为规范，再回到服务端验证它的工程落点，能更清楚地理解"内置系统智能体"与普通 agent 的差别。

身份与模板注入。 指令中的 {{AGENT_NAME}} 是一个占位符而非格式化动词。之所以不直接硬编码 "You are Mika"，是因为 runtime brief 已经宣布了 "You are: <name>"——一旦拥有者重命名，硬编码文案会与之矛盾。MikaSystemInstructions 在 builtin_agents.go 中用 strings.ReplaceAll 完成替换，空名回退到 MikaDefaultName = "Mika"；注释还解释了用占位符而非 format verb 的另一个原因：避免提示词中意外出现的 % 触发格式化错误。

行模型特殊但保持 kind='user'。 builtin_agents.go 解释了关键设计：Mika 行保持 kind='user'，因为该 schema 中 kind='system' 的含义是"不可见的执行载体"（从 agent 列表与指派界面隐藏、runtime 消失时硬删除），而 Mika 三者皆不需要——它必须可见、可被指派、可持久。

创建即幂等。 mika_agent.go 的 CreateMikaAgent 按 workspace 内 system_key 幂等，而非按名字（名字可编辑）。前置的 GetAgentBySystemKey 查找只是快速路径；真正的串行化是事务内 pg_advisory_xact_lock(hashtextextended('mika:'+workspaceID, 0))，锁内再次复查，防止两个成员同时点击 "Start with Mika" 时各自插入、产生两个存活 Mika（迁移 172 的唯一索引覆盖 (workspace_id, owner_id, runtime_id, system_key)，仍会放行不同 owner/runtime 下的第二个实例，所以代码注释明确该 advisory lock 才是"每个工作区一个 Mika"的真正不变量）。

邀请与启动属性固定。 创建参数同样在 mika_agent.go 常量中锁定：mikaAgentMaxConcurrency = 3、Visibility = "workspace"、PermissionMode = "public_to"，并立即把整个 workspace 注册为调用目标（每个成员都可以与其聊天并指派工作）；头像使用统一的 emoji: 标记（🦄）而非手写 data-URI SVG。描述（description）是多语言并存储在行上的可编辑字段，因为它是用户可见文案、产品不再回收。公开的 CreateAgent API 不接受 kind 与 system_key，从根上杜绝客户端伪造出另一个接收系统指令层、或破坏每工作区单例的 agent。

只读展示系统半部分。 mika_agent.go 的 systemInstructionsFor 在 UI 中以只读方式暴露系统指令层，普通 agent 返回空串——因为它们的完整提示词本就在可编辑的 Instructions 字段中，而 Mika 的不可编辑系统半部分必须展示出来以避免困惑。

引导 kickoff 的注入。 mika_onboarding.go 附近的注释揭示了引导的技术形态：一次会话可含一个服务端撰写的引导 kickoff（一段成员可见的开场白 + 一个隐藏 kickoff），kickoff 行不带 task 写入，成员的第一个真实消息才触发后续流程；该技能块的装载指令（"Load and follow the built-in multica-onboarding skill, silently"）作为产品上下文出现在会话内，且刻意不广播为聊天气泡。这正是 INSTRUCTIONS.md"使用 multica-onboarding 技能"一句在实现层的落地。

小结：把行为准则当代码维护

Mika 的 INSTRUCTIONS.md 是一份"以 Agent 为读者"的行为契约，其价值恰恰在于它被当作一等代码资产随二进制发布、可与工作区 notes 分层叠加、由测试守护（TestComposeMikaInstructions、TestMikaSystemInstructionsUsesTheCurrentDisplayName 等见于 mika_agent_test.go，覆盖空 notes 拼接与重命名后的模板替换）。理解这份文件及其配套技能与处理逻辑，无论你是想在自托管部署中驾驭默认的 Chief of Staff，还是想借鉴"系统层指令 + 可编辑层 notes + 运行时技能"的三层提示词设计来构建自己的内置 agent，都能从中获得一份可直接对照源码研读的完整样本。

阅读建议：先通读 INSTRUCTIONS.md 掌握行为规范，再对照 builtin_agents.go 理解指令的分层与装载，最后在首次创建/交互时参考 multica-onboarding/SKILL.md 与 mika_agent.go 验证端到端行为。