作者：胡亦锟（易仑）
依托钉群无人值守、跨群会话记忆、组织知识检索及前端专业 Skill， 阿里云云原生消息前端团队自研的内部研发协作平台 Domino 正经历关键演进——从单一的代码执行工具，升级为能够理解团队上下文、持续沉淀演进并闭环真实交付的研发 Agent 系统。
从上一次实践说起
在此前，Domino 诞生于内部的一个前端源码定位工具，随着能力的不断增强，逐渐演变为了覆盖需求理解、编码、评审、部署和验收的研发平台。
那一阶段解决的核心问题是：怎样让 CodingAgent 在真实仓库和真实研发链路中完成一次任务。
这一阶段建设了独立沙箱、单应用任务、Flow 多应用流水线、CodeReview、O2/AoneCD 部署和 AI 页面验证，让 Agent 不再只生成一段代码，而是可以真正把代码送进研发流程。
但投入日常使用后，一个更基础的问题逐渐浮现：
- 用户通常不会先打开一个 AI 平台，再思考该创建什么任务；问题往往直接发生在钉群里。
- 大量研发问题并不需要立即创建沙箱，可能只是查询历史决策、确认发布流程或定位一段已有逻辑。
- 一个任务结束后，Agent 获得的业务背景和团队结论也随会话一起沉没，下次仍要从头解释。
- 通用 CodingAgent 会读写代码，却不了解控制台项目的工程规范、国际化链路、登录方式、设计稿结构和发布验证方法。
如果这些问题不解决，Agent 再强也仍然是一个“需要人主动操作的高级工具”，而不是团队日常协作的一部分。
因此，Domino 平台最近一轮演进的重点不再只是“把一个任务做得更自动”，而是重新回答三个问题：
- Agent 如何自然地进入团队每天已经在使用的协作入口？
- 不同群、不同会话中的上下文，如何沉淀为可以复用的组织知识？
- 通用模型如何真正掌握前端控制台研发中的专业方法？
对应的答案，是一套由 ConsoleAgent、KBase 空间记忆、知识检索、专业 SKILL 与 SandboxAgent 组成的分层 Agent 体系。
不是一个“全能 Agent”，而是两类 Agent 接力。
系统没有继续把所有能力塞进一个 Agent，而是将“理解与路由”和“执行与交付”拆给两个生命周期完全不同的角色。
钉群 @机器人 │ ▼ ConsoleAgent（长期入口） │ ├── 群上下文 ──▶ 延续当前讨论 ├── KBase 记忆 ─▶ 找到跨群、跨会话的团队约定与历史决策 ├── 知识库 ─────▶ 查询产品、流程和架构知识 ├── CodeWiki ───▶ 查询代码实现事实 ├── 直接答疑 │ └── 需要真实仓库或代码改动 │ ▼ 创建单应用任务 / Flow │ ▼ SandboxAgent（任务执行） │ 读码 → 改码 → 验证 → CodeReview → 部署 → AI 页面验证
ConsoleAgent：钉群里的常驻研发入口
ConsoleAgent 面向高频、碎片化、随时发生的研发问题。管理员将 Agent 绑定到钉群后，群成员只需要 @Domino 助手，就可以直接询问：
- 某个控制台功能是如何实现的？
- 这类变更应该走哪个发布流程？
- 团队之前对这个方案做过什么约定？
- 页面上这句中文文案对应哪个代码位置？
- 帮我到真实仓库里排查，必要时直接修改并验证。
这里的“常驻”不是要求某个 FaaS 进程永远不重启，而是业务语义上的常驻：每个群都持久化自己的 conversationId、sessionId 和消息历史。底层实例发生切换后，ConsoleAgent 仍可以恢复会话，而不是让用户重新建立上下文。
同时，它按照钉群交互特性做了无人值守约束：不使用只能在 Web 页面中点击的交互式问答工具；信息不足时直接在群里提出问题，等待下一条消息；可以直接回答的问题即时回复，需要长时间执行或修改代码的问题则自动创建 Domino 任务并返回链接。群成员不需要守着一个流式窗口，也不需要知道沙箱、模型和任务编排的内部细节。
SandboxAgent：进入真实仓库完成交付
ConsoleAgent 不会在 Console 服务目录里“猜”业务代码，也不会直接修改业务仓库。只要问题需要深入读取真实代码、运行命令或产生变更，就交给 SandboxAgent。
SandboxAgent 由单应用任务或 Flow Stage 触发。系统会准备独立沙箱、克隆目标仓库、创建工作分支，并注入任务上下文、SKILL 和 MCP 授权。它负责完成真正的工程执行：
理解需求 → 定位代码 → 实施修改 → 构建/测试 → Git 推送 → CodeReview → 绑定变更并部署 → AI 页面验证
这种边界带来两个直接收益：
- 轻量答疑不再为每个问题创建昂贵沙箱。
- 任何代码修改都发生在隔离、可追踪、可以验证的研发环境中。
由此形成了一个清晰原则：ConsoleAgent 负责理解、检索和路由，SandboxAgent 负责在真实环境中执行和交付。
从“聊天记录”到“团队记忆”
让 Agent 进入群聊并不难，难的是让它既能延续当前讨论，又不会被某一个群的偶然信息绑住。
为此，Domino 没有把所有消息简单拼进模型上下文，而是建立了三层不同粒度的认知来源。
第一层：群级 Session，保存局部上下文
每个钉群维护独立 Session。同一个群后续追问可以自然延续，例如用户先问“这次变更为什么失败”，下一轮只补充“那预发版本应该看哪个”，Agent 仍然知道讨论对象。
不同群的 Session 相互隔离。一个业务群里的临时讨论不会直接污染另一个群，也避免把不适合跨群传播的聊天内容无差别共享。
Session 解决的是“这个群刚刚在聊什么”，但它不能独立解决跨群、跨时间的知识复用。
第二层：KBase 空间记忆，连接跨群跨会话的历史
对于需要长期复用的团队上下文，ConsoleAgent 会在回答前检索 KBase 空间记忆。空间记忆与某一次对话解耦，因此同一条经过沉淀的团队约定，可以被不同钉群、不同成员和后续新会话重新召回。
适合进入空间记忆的内容包括：
- 团队已经确认的技术决策及取舍原因；
- 项目长期有效的目录、模块和负责人信息；
- 特殊环境约束、联调方式和排障结论；
- 多次协作后形成的研发规范与操作约定。
这让 Domino 获得了一种过去单次 Agent 会话不具备的连续性。一次讨论不再只是“这次回答完就结束”，其中有复用价值的结论可以成为团队之后解决问题的起点。
空间记忆也有明确边界：它服务于团队共享上下文，不用于保存个人隐私或把整段群聊原样归档；更新与删除都需要定位明确的记忆条目。目标是积累经过提炼的事实和决策，而不是不断膨胀的聊天日志。
第三层：知识库与 CodeWiki，连接正式事实源
记忆适合保存经验与决策，但不能代替正式文档和代码事实。ConsoleAgent 会根据问题类型选择不同检索路径：
- 产品知识、研发规范、部署流程、架构说明等问题，查询团队知识库；
- 实现逻辑、接口定义和代码结构等问题，优先查询 CodeWiki 和代码平台；
- 页面中文文案无法直接在源码中命中时，先通过国际化反查 SKILL 找到 key，再定位调用位置；
- 多次检索仍无法得到可信答案时，不继续编造，而是委派 SandboxAgent 进入真实仓库排查。
三层上下文的职责因此变得明确：
这并不是简单地给模型“塞更多上下文”，而是让 Agent 知道：什么是当前对话，什么是历史经验，什么才是需要引用的正式事实。
SKILL：把前端工程经验变成 Agent 可执行的方法
通用模型可以写 React，也可以解释 TypeScript，但真实控制台研发中最耗时间的部分，往往是模型不知道的团队隐性知识：这个项目属于哪套框架、请求应该怎么封装、中文文案存在哪里、沙箱为什么没有登录态、设计稿如何落到现有组件、改完后怎样验证预发。
过去这些知识依赖熟悉项目的工程师口口相传。现在，其中稳定、可复用的部分被提炼成 Domino 内置 SKILL。
SKILL 不是一段万能提示词，而是一份带触发条件、执行步骤、工具选择和验收标准的工程方法。Agent 只在命中场景时加载对应内容，避免每轮对话都携带所有规范。
面向前端控制台的专业能力，最小化跨角色协作门槛
mq-frontend-skill：识别工程，再按项目规范开发
这是消息控制台前端研发的总入口。它先识别目标项目，再路由到对应的工程子技能：
xconsole：覆盖 RocketMQ、EventBridge、KafkaNext 等现代控制台工程；recore：覆盖 MNS、AMQP、MQTT、Kafka 等存量框架工程。
技能中固化 TypeScript、组件复用、请求封装、样式、国际化和验证方式等约束。Agent 不再把所有前端仓库当成同一种 React 项目，而是按真实工程栈选择实现方式。
find-i18n-key：从页面中文反查真实源码
控制台代码通常不硬编码中文。用户说“帮我改一下‘创建实例’按钮”时，直接搜索中文往往没有结果。
find-i18n-key 会先从国际化资源反查文案 key，再到代码平台或真实仓库中定位 key 的调用位置。它把“用户看到的页面语言”转换成“工程中的代码坐标”，显著缩短问题定位路径。
frontend-sandbox-auth：解决沙箱页面登录与接口权限
前端页面在沙箱中启动后，常见问题不是代码编译，而是预发接口的 Cookie、sec_token、代理和启动参数不匹配。这个技能沉淀了沙箱代理下的认证配置与排查方法，让 Agent 能区分代码缺陷和环境登录问题。
medusa：把国际化变更纳入交付
新增文案不是只改一个 key。medusa 覆盖多语言文案查询、写入、批量更新、翻译、审计和发布，让国际化资源和代码变更进入同一条 Agent 工作流。
mgdone-dsl-analyze：把设计稿变成结构化输入
面对 MasterGo 设计稿，Agent 不再只依赖截图猜布局，而是通过 MCP 获取设计 DSL，分析组件层级、布局和样式数据，并将原始设计信息归档。设计输入因此从“视觉参考”升级为可以分析和追踪的结构化上下文。
ai-testing：让“页面看起来没问题”变成可执行验证
完成编码和部署后，Agent 可以根据任务目标生成 AI Testing 指令，对预发控制台执行 E2E、冒烟或回归验证，并持续跟踪结果。验证通过或失败后还可以发送钉钉通知。AI 验证能力通过对接云原生 SRE 团队的 SQA 平台工具，让 AI 结合任务执行完整上下文自动生成自然语言的验证指令，不仅关注增量变更结果验证通过，同时保证存量页面功能不被影响。
这使前端任务的终点从“代码已经提交”进一步推进到“页面行为已经验证”。
不只会执行，也先学会澄清
/brainstorming 用于在复杂实现前澄清目标、约束和验收标准。它体现了一项持续验证的判断：很多失败不是模型不会写代码，而是在动手前没有把问题理解清楚。 同时，凭借着生产中人为解决问题的经验积累以及多层上下文知识的来源，在任务执行的事前、事前、事后系统提示词都进行了充分约束，保证任务的执行方向与质量。
You are a senior engineer who ships production-quality code. Follow these principles on every task: ** More Prompts ... **
在任务页输入 /，用户也可以显式选择 SandboxAgent 当前环境中的内置 SKILL。运行时技能清单由平台统一管理和展示，不再要求每个用户手工复制 Prompt。
SKILL 与 CLI/MCP：工程方法与平台工具的分工
在 Domino 中，SKILL 与 CLI/MCP 解决的是两个不同层面的问题：
- SKILL 固化工程方法： 描述什么时候触发、按什么步骤执行、使用哪些检查方式，以及达到什么验收标准。
- CLI/MCP 连接真实平台： 通过标准化工具接口访问知识、代码、协作、设计和发布系统，把方法落实到实际数据与操作上。
SKILL 决定“怎么做”，CLI/MCP 决定“能访问什么”。两者结合后，Agent 才能把团队经验转化为可执行、可验证的研发动作，而不是停留在通用建议层面。
例如“根据设计稿开发一个控制台页面”并不是一次模型生成，而是一连串的工作流：
1. brainstorming 先澄清交互和验收标准；
2. mgdone-dsl-analyze 通过 MasterGo MCP 获取结构化设计数据；
3. mq-frontend-skill 根据工程类型约束实现方式；
4. find-i18n-key 与 medusa 处理已有及新增文案；
- SandboxAgent 在真实仓库中编码并运行构建；
- 代码进入 CodeReview 和 O2 迭代；
7. ai-testing 在预发页面验证最终效果。
模型能力仍然重要，但决定生产可用性的，是模型能否调用真实系统，并遵循团队已经验证过的方法完成闭环。
平台访问基于 OAuth 认证对接 Aone 开放平台。MCP 工具调用沿用当前授权主体的身份：ConsoleAgent 使用其配置的授权，任务委派后 SandboxAgent 优先使用真实 requester 的授权。服务端不需要保存平台密码，授权失效时也能明确反馈具体平台能力不可用，从而提升跨平台工具调用的安全性与可追踪性。
目前 Domino 已接入 Aone 协作平台、代码平台、知识平台、变更发布、O2、语雀、MasterGo 等 MCP。系统会按 Agent 角色、用户授权和工具白名单注入必要能力，避免无关工具占用上下文，也避免 Agent 获得不必要的操作范围。
从一条钉群问题，到一次可追踪交付
把前面的能力串起来，一次真实协作可以是这样的：
用户在业务群里问：“实例详情页的消息堆积量为什么和监控页不一致？如果是前端问题帮我修一下。”
ConsoleAgent 首先延续当前群 Session，并检索 KBase 中是否有相关历史结论；随后查询知识库和 CodeWiki，确认指标口径及已有实现。
如果知识中已经有确定答案，它直接在群里回复并给出依据。如果必须读取最新仓库、复现页面或修改代码，它会查询已注册应用，创建一个单应用任务，并把任务链接发回钉群。
任务创建时，真实提问者的工号和昵称会作为 requester 透传。后续沙箱、MCP 授权、任务记录和 Dashboard 统计归属实际用户，而不是机器人创建者或内部 CLI 身份。
SandboxAgent 进入独立沙箱后：
- 使用前端项目 SKILL 识别工程规范；
- 结合文案反查、代码搜索和真实运行环境定位问题；
- 修改代码并完成构建、测试；
- 用户在任务对话中确认结果；
- 将任务记录分享给评审者，或委派协助者继续处理；
- 通过「任务改动提交」完成 Git 推送、CodeReview、O2 变更绑定和部署；
- 使用 AI Testing 验证预发页面，最终把结果带回研发协作链路。
从群聊答疑到代码交付，不再是两个互不相干的系统，而是同一条可以接力、追踪和统计的链路。
沙箱工作记录：从个人会话到多人协作
沙箱不是一次性的黑盒执行环境。任务过程中的对话、Agent 工具调用、阶段进度、代码变更、CodeReview、部署状态和页面验证结果，都会持续保存在 Console 中，形成一份可以回看、分享和继续推进的工作记录。
这使协作方式发生了变化：分享的不只是一个最终链接或一段代码，而是完整的研发上下文。
对于控制台需求，这种上下文共享尤其重要。接口实现者不必再从零拼接需求描述、页面现象、调用链、相关代码、测试账号和验证结果；任务记录可以一次性把这些信息带齐，让实现者直接进入问题定位和方案落地阶段。需求提出者、产品、前端、后端和测试之间因此少了多轮转述与反复确认，跨角色沟通成本显著下降，交付节奏也更容易保持连续。
- 可分享：通过任务或对话链接让评审者了解需求、过程和当前结果；只读场景可以安全查看，不必进入沙箱操作。
- 可交接：任务负责人可以指定协助者，并附带当前背景、测试账号、截止时间和后续工作；协助者进入同一任务后可以继续对话和处理代码。
- 可追溯：每次输入、Agent 回复、工具结果和阶段状态都留在同一条记录中，方便复盘“为什么这样改”和“问题在哪一步解决”。
- 有边界的多人协作：任务创建者、真实 requester、指定协助者和管理员分别拥有不同的读写权限；同一 Session 的执行权也按请求隔离，避免多人查看或插话时误中断彼此的操作。
当前协作以任务负责人/提问者与指定协助者为核心关系，但底层记录和权限模型已经把 Agent 任务从“个人草稿”提升为团队可以共同阅读、交接和验收的研发空间。
这次演进真正改变了什么
如果只看功能列表，这一轮新增的是钉群机器人、记忆、知识库和若干 SKILL。但从工作方式上看，变化更深：
Domino 的定位也随之发生变化：它不再只是一个“云端 CodingAgent 控制台”，而是在尝试建设一套团队级 Agent 基础设施——有长期入口，有共享记忆，有正式知识，有专业方法，也有真正能执行和交付的工作环境。
上线后的使用截图
7 月初上线，统计至 7 月 31 日，月内发起 135 代码任务，完成 127 次群内业务答疑，20+ 团队活跃用户，覆盖 60%+ 日常任务答疑和存量页面的开发工作。
业务答疑
代码任务委派
代码任务详情以及一站式的研发任务部署与验证
群内知识纠正与记忆沉淀
系统核心模块矩阵
一些阶段性认识
1. Agent 要进入工作，而不是让工作迁移到 Agent
钉群不是新增的展示渠道，而是多数问题天然发生的地方。只有进入现有协作入口，Agent 才能覆盖那些用户不会专门创建任务、却每天大量消耗研发时间的问题。
2. 上下文越多不一定越好，分层比堆叠更重要
群 Session、空间记忆、知识库和代码事实有不同可信度与生命周期。把它们混成一段超长 Prompt，不仅浪费 token，也会模糊事实边界。让 Agent 按问题检索、按来源判断，才能让记忆真正提升而不是干扰回答质量。
3. 团队经验必须从 Prompt 走向可维护的 SKILL
一次性的 Prompt 很容易过期，也难以验证。SKILL 将触发条件、工具链和验收方式组织成版本化资产，可以由领域工程师持续维护，并在 ConsoleAgent 与 SandboxAgent 中按需分发。
4. 无人值守不等于无人负责
ConsoleAgent 可以自主检索、答疑和委派任务，SandboxAgent 可以自主编码和验证，但 CodeReview、部署确认和最终发布仍保留人的决策节点。目标不是移除责任人，而是让人从重复执行中退出，把注意力留给业务判断和风险决策。
5. 生产可用来自边界，而不是“全能”
ConsoleAgent 不直接修改业务代码，SandboxAgent 不默认继承整个群聊，空间记忆不保存个人信息，MCP 按授权和白名单注入。正是这些边界，让 Agent 能力可以被放心地放进真实研发流程。
