Multica 内置系统智能体 Mika一份面向 Agent 的 Chief of Staff 行为准则与实现解析【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica本文围绕 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 成员收到下午的早晨摘要。仓库中确实存在该 CLItrigger-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原则是即使专精智能体看起来很诱人也优先默认项——每多一个对象就是成员与第一个可见成果之间多一道确认步骤和一个未知数。引导期间绝不创建 squadautopilot 只允许用于上述 digest 玩法或成员明确要求时。预览与确认、经 issue 开工、完成引导三节构成首次会话的收尾闭环确认后先创建已确认的 project 或 specialist再创建带足执行上下文结果、输入、交付物、约束、完成标准的 issue 并指派成员希望立即开工时用todo指派给 agent 的todoissue 会启动 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 的另一个原因避免提示词中意外出现的%触发格式化错误。行模型特殊但保持 kinduser。builtin_agents.go 解释了关键设计Mika 行保持kinduser因为该 schema 中kindsystem的含义是不可见的执行载体从 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:标记而非手写 contenteditable="false">【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Multica 内置系统智能体 Mika：一份面向 Agent 的 Chief of Staff 行为准则与实现解析
Multica 内置系统智能体 Mika一份面向 Agent 的 Chief of Staff 行为准则与实现解析【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica本文围绕 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 成员收到下午的早晨摘要。仓库中确实存在该 CLItrigger-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原则是即使专精智能体看起来很诱人也优先默认项——每多一个对象就是成员与第一个可见成果之间多一道确认步骤和一个未知数。引导期间绝不创建 squadautopilot 只允许用于上述 digest 玩法或成员明确要求时。预览与确认、经 issue 开工、完成引导三节构成首次会话的收尾闭环确认后先创建已确认的 project 或 specialist再创建带足执行上下文结果、输入、交付物、约束、完成标准的 issue 并指派成员希望立即开工时用todo指派给 agent 的todoissue 会启动 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 的另一个原因避免提示词中意外出现的%触发格式化错误。行模型特殊但保持 kinduser。builtin_agents.go 解释了关键设计Mika 行保持kinduser因为该 schema 中kindsystem的含义是不可见的执行载体从 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:标记而非手写 contenteditable="false">【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考