当 Agent Harness 装到一个团队身上：一个 AI Native 工作台的工程复盘

30 天魔咒：为什么"AI 写得快"还不够

本文的素材来自国内某大厂研发团队 2025–2026 年内部技术分享中的工程复盘，公开版本保留方法论与架构、隐去内部专有系统名与具体度量数字。这是一篇"案例 → 抽象 → 可迁移模式"的文章，不是一份产品介绍。

一个反常识的观察

过去半年，几乎所有研发团队的内部周报里，都在讲"AI 编码占比上升到 30% / 50%"这件事。Cursor、Claude Code、各家 IDE 插件让人觉得"AI 已经在替我们写代码"。但当这个团队复盘集团层面的端到端度量时，他们看到了一个反直觉的数字：

Coding 阶段确实更快了。但有 AI 参与的需求，从立项到上线的端到端交付周期，仍然接近一个月。测试阶段的耗时甚至比之前更长 —— 因为"AI 写得太快，人需要花更多时间理解和确认产物"。

换句话说：在 IDE 里更快地生成代码，并不能带来真正的 10 倍提效。真正的瓶颈在工作模式本身，不在编码速度。

四个典型痛点

团队复盘下来，把"AI 已经够强但效率没起飞"这件事归纳成四个反复出现的痛点：

归纳成一句话：当前的 AI 使用模式更接近"增强版搜索引擎"，能力确实在那里，但调用成本太高、整合度太低、跟研发工作流之间存在明显断裂。

团队的核心判断

基于这些观察，团队做了一个很硬的判断：

团队的核心竞争力不再是「人均代码产出」，而是「人均 AI 调度能力」—— 能否让 AI Agent 高效、安全、持续地替代人完成大量重复性研发工作。

这个判断本身没什么了不起，行业里很多人都说过类似的话。真正难的是把它翻译成一套工程产物。下面六章讲的就是这个翻译过程：他们如何从"团队的核心是 AI 调度能力"这一句话，走到一个能跑、能调度、能闭环的工作台。

五个解题方向

具体到落地路径，团队选了五条线同时推进：

• 工具整合：把零散的需求 / 监控 / 代码 / 即时通讯平台聚合到统一工作台，消除上下文切换成本。
• 模式升级：从「问答式 AI」升级为「Agent 自主执行 + 人工决策介入」。
• 并行提效：通过 Git Worktrees 支持同仓库多任务并行，把等待时间转化为产出。
• 经验沉淀：通过预制 Prompt 模板和 Skill 体系，把优秀实践标准化、可复用。
• 度量建设：分层度量（任务级 / 工作流级 / 团队级），让 AI Native 转型可量化、可展示。

这五条线最终拧成的产物，就是接下来要讲的工作台。它不是一个 IDE 插件，而是一个装在团队身上的 Agent Harness。

先看一张图：工作台的整体架构

在拆细节之前，先把整套工作台压成一张图。后面 6 章会从不同切面挖进去，但读起来始终可以回到这张图找位置。

读这张图的三个要点：

• ① 入口是多元的：人不是唯一触发源 —— 监控报警、Bug MQ、定时任务都是平等的"调用方"。这是它跟传统 Copilot 类工具最本质的差异。
• ② 会话居中：所有触发源最终都落到一个会话上；运行时和工作流都挂在会话之下。这就是为什么"重新定义会话"是整个架构的支点。
• ③ 横向是底座、纵向是流水：Skills × MCP 是横向能力底座，工作流是纵向时间线，知识层在旁边按需供给上下文。三者解耦才能各自演进。

重新定义「会话」：工作台的最小工作单元

如果只能记住一个设计决策，就记住这个：在 AI Native 工作台里，「会话」是承载一切工作的基本单元。一次代码改动、一段问答、一次工作流执行，都对应一个独立的会话。这个抽象一旦确立，后面所有事情才有共同的容器去挂载。

会话 = 任务容器，不只是聊天窗口

传统聊天窗口的"会话"是对话历史的容器。这里的「会话」被重新设计成任务的执行容器：每个会话绑定一个工作目录（决定所有 Git 操作 / 构建 / 测试的根目录）、一种类型（对话 / 流程 / 自动）、一种执行位置（本机进程 / 云端容器）。

每个会话有统一的生命周期状态机：

待启动  →  运行中  →  待审阅  →  已结束
            ↓
        异常状态高亮，方便人工介入

状态由系统自动判定。在列表 / 看板视图上，不同状态以不同颜色区分。这件事看起来很小，但它是"让 Agent 自主跑"的前提 —— 没有清晰的状态机，人就不知道什么时候该接手。

列表 vs 看板：同一份数据的两种视图

会话列表 + 看板视图共享同一份数据，任何变更实时同步。看板列等同于状态机的列：把"待审阅"那一列拉满，就知道现在有多少个 Agent 跑完正等你看。这是一种把 Agent 工作可视化的手段，对团队 Lead 尤其重要。

消息模式 vs TUI 模式：两种对话形态

同一个会话内，AI 交互可以在两种视图之间切换：

• 消息模式：富界面。气泡、工具卡片、Diff、Markdown 都拆成可折叠的卡片。适合查看 Diff、复制引用、做 Code Review。
• TUI 模式：保留终端原貌。所有颜色、动画、键盘交互（Tab 补全、Ctrl+C 中断、方向键查历史）都与命令行一致。适合需要内联编辑的场景。

切换会重启 AI 进程，但上下文不丢。云端会话只支持消息模式（终端动效云端没必要传回来）。这套设计承认了一个事实：没有一种 UI 能同时满足"看 Diff 方便"和"键盘交互顺手"，那就两个都给。

顶部信息栏：会话状态尽在一栏

会话页面顶部有一条信息栏，从左到右依次是：标题、信息气泡、工作目录、上下文、终端原始输出、视图切换、上云 / 拉回。每个气泡点开都是一个详情面板。其中两个最重要：

• 「上下文」气泡：按模型分组展示 Token 用量、当前 Prompt 长度、工具与技能调用次数、缓存命中率。这是排查"为什么这次回答这么慢 / 这次幻觉这么多"的第一现场。
• 「终端」气泡：保留模型与工具交互的原始日志、拦截到的接口请求原文，可下载。这是排查"看到的与实际不一致"问题的底牌。

把"会话级观测"做成一等公民，是这个工作台和大多数 IDE 插件最大的区别 —— IDE 插件假设你只关心结果，工作台假设你随时可能要回放过程。

本机 ↔ 云端：一次切换，无缝继续

会话可以在本机进程和云端容器之间随时切换，工作目录、Git 状态、当前上下文都会一并带过去。上云的过程：

打包工作目录（自动排除依赖与产物）
    → 上传
    → 云端容器还原
    → 云端会话从断点继续
    → 本机进程在云端就绪后才停止

拉回本地是镜像过程，本地若有未提交改动会提示合并。上传中断、容器启动失败、本地目录已删除，每条异常路径都有明确的回退策略，原模式始终保持可用。"无缝迁移"是一个工程能力 —— 中间要做的事比看起来多得多。

灵动岛：常驻屏幕的提醒入口

桌面端有一个独立的悬浮小窗，主窗口最小化或关闭都不影响它。空闲时是一颗极简小药丸，有任务时显示统计数字（"3 个运行中、2 个待审阅"）。这个细节很容易被低估，但它解决的是一个非常实际的问题：当你同时在跑 5–10 个 Agent 任务时，不能要求人主动去看主界面才知道有几个跑完了。提醒必须是被动到达的。

多运行时：让 Agent 跑在任何地方、被任何东西调起

如果说"会话"是工作台的基本工作单元，那么"运行时"就是这些会话真正跑起来的地方。这个工作台的运行时不只是本机进程，它包含云端容器、IM 机器人、移动端、以及由消息队列 / 监控 / 定时任务触发的自动会话 —— 把工作台从「AI 监控员」推进到「AI 调度者」。

云端运行时：让任务脱离桌面

工作台支持把一个会话整体搬到云端容器继续执行。云端会话能完成大部分本机能做的事情：跑 AI 协作能力（包括工作流）、跑测试与构建、提交代码与推送评审、调用各种外部应用。

典型上云场景：

• 构建 + 测试超过 10 分钟的长任务（让桌面解放）；
• 需要并行跑多个长任务（桌面跑不过来）；
• 希望从手机或另一台电脑观察进度；
• 部分代码不能落到本地的安全场景（沙箱化执行）。

云端容器是 Linux 沙箱，所以无法访问本机硬件 —— iOS 模拟器、本机 Docker、本机数据库、本机特殊工具链都不行。这部分场景仍需留在本机。

会话上云后，桌面端、手机网页、另一台电脑可以同时观察同一会话，任何一端的输入、中断、回答都实时同步。桌面端断网，云端继续跑；网恢复后自动从缓冲区拉历史进度（30 分钟内）。30 秒一次心跳保活，超过 30 天无活动自动回收容器。

安全侧：容器与公网隔离，仅放行内部网关；每个会话独占容器互相隔离；管理员侧有沙箱监控页面，可查看所有运行中容器的 CPU / 内存 / 磁盘 / 网络，并支持一键重启或销毁。

多入口自动调度：从被动响应到主动触发

云端运行时真正发挥威力的地方，是它支持被外部事件直接触发。这里落地了三类自动调度入口：

这三类入口的共同点：触发不再依赖人类点击，AI 主动响应外部事件，云端运行时承载这些「无人值守」的工作。这一步打开后，"AI 调度者"才真正从口号变成能跑的东西 —— 工作台不再只在我打开它的时候工作，它在 24×7 工作。

IM 机器人：第三个执行入口

除了桌面端和移动端，团队主用的即时通讯工具是工作台的第三个执行入口，不开应用也能触发或接收任务。三种典型用法：

• 评审通知（出向）：提交代码后自动发到群里，附评审链接、@ 评审人、影响范围、提交列表。
• 群消息触发（入向）：群里发 @bot 修一下 Bug-12345，机器人识别关键词后自动跑对应工作流，进度回贴到群里。
• 私聊提醒：任务完成后单独通知发起人，适合通宵跑的长任务。

通知策略支持四档（实时 / 关键节点 / 静默 / 自定义），避免刷屏。

移动端：随时观察与干预

移动端没做独立 App，而是直接做成 IM 内的 Web 应用 —— 减少更新成本。移动端能做：

• 拉云端会话列表（实时增量更新）；
• 看实时消息流与工具调用卡片；
• 查看只读的 Diff 卡片；
• 发消息 / 中断 / 回答 AI 抛出的问题；
• 直接创建云端会话；或远程让桌面端代为创建。

移动端不支持本机会话、TUI 视图与代码编辑 —— 它是桌面端的"观察镜与干预面板"，不是 IDE。重要事件（待审、出错）通过 IM 私聊推送，点击消息一键打开手机端详情。

小屏不适合长 Prompt，也不建议在手机端做关键发布决策。但"在路上能立刻看一眼任务跑得对不对、需不需要中断"这件事，本身已经极大改变了 AI 协作的节奏 —— Agent 不再"在你电脑前才存在"。

工作流：把「问答式 AI」升级为「流水线式 Agent」

本章是整个工作台最具差异化的设计。前面讲会话和运行时，主要是基础设施。"工作流"才是真正把 AI 从「增强搜索引擎」推上「Agent」位的发动机。

核心矛盾：AI 快了，但人的参与模式没变

团队复盘大量 AI 编码使用情况后发现一个矛盾：

AI 的执行速度提上去了，但人的参与模式没有变。研发人员从"写代码的人"变成了"盯 AI 写代码的人"，在每次任务中仍然承担着信息搬运、上下文组装、状态同步等大量非创造性工作。

具体来看，这些成本集中在四个环节：

1. 上下文组装：修一个 Bug，需要在工单系统看详情 → 在代码仓库定位文件 → 在监控平台查报警关联 → 把这些信息拼成 Prompt 喂给 AI。一次任务的上下文准备耗时经常超过任务本身。
2. 状态同步：修完代码后，需要手动回工单系统更新状态、写评论、贴评审链接，再去 IM 通知相关人。漏掉任何一步，工作项就挂在那里。
3. 串行等待：受限于 IDE 单会话模式，同一时间只能推进一个 AI 任务。
4. 经验无法复用：同样类型的任务，每个人的 Prompt 写法不同，产出质量参差不齐。

工作流的四个硬约束

"工作流"模块的设计目标是：提供一个以「会话」为单位的任务容器，把 AI 编码能力和外部平台的读写能力整合在同一个运行时里，让工作流能够在这个容器中自主推进。

四个底线约束 —— 没有这些，工作流就退化成"自动跑的脚本"：

三条内置工作流

D1 · 需求开发：工作项到部署的 9 步流水线

从拿到一条需求工单开始，到代码上线、知识归档结束，共 9 个步骤。其中若干步是 🔒 标记的人工卡口，AI 在此处停下等待确认后才继续。这条工作流是覆盖面最广、步骤最多的一条。

在动手之前，工作台会先做一轮需求前置准备：需求的检查评分、需求点提取、细节澄清、接口文档和 UI 设计图的补充、仓库的确认 —— 待这些就绪后才允许进入"AI 执行"阶段。这一步是"垃圾 Prompt 进，垃圾代码出"的根本对策。

D2 · Bug 修复：从工单到修复闭环的 9 步流水线

传统方式下，一个 Bug 从接到到修完，需要在工单（看详情）→ IDE（定位代码）→ 终端（跑测试）→ 评审平台（推评审）→ 工单（回写状态）→ IM（通知相关人）之间反复跳转，每一步上下文切换都是成本。

触发方式有三种：

1. 工作台自动显示本人关联的 Bug，云端自动监听 Bug 状态并预执行修复；
2. 输入框打 /Bug 修复 后输入工单编号；
3. 在工单详情页点「AI 修复」按钮。

它和"直接和 AI 对话修 Bug"的区别在于：工作流保证了"校验 → 复现 → 分析 → 修复 → 验证 → 回写"的完整执行，不会因为人的疏忽跳过某个环节。"测试没跑就提交"、"修完忘记回写"这些问题，在工作流里不会发生。

D3 · 线上问题排查：从监控 issue 到修复回写的端到端闭环

线上问题排查和 Bug 修复看起来类似，但数据来源和处理逻辑有本质区别。Bug 修复的输入是人工提的 Bug 单，通常已经包含复现步骤和期望行为；线上问题排查的输入是监控平台自动收集的 issue，原始数据更"散"，可能只有一条报警、一段 JS Error 堆栈、或者一个用户反馈截图，需要先做一轮深度信息聚合才能定位根因。

"深度分析"环节做的事：

1. 拉取监控问题详情与实时模块映射；
2. 自动抓取描述中引用的 IM / 文档 / 工单链接；
3. 按问题类型关联报警数据或 JS Error 堆栈；
4. 评估当前数据是否足够定位根因。

如果数据不足以定位到具体功能点，流程会停下来通知补充，不会硬猜。这是值得抄的设计 —— 让 Agent 学会说"我不够用"。

工作流的"下一步"：从平台统一管控到仓库自治

这三条内置工作流是通用的。但实际研发中，不同业务方的流程差异很大：

• 某些仓库有自己的 lint 规则和提交规范，跟通用流程的默认配置不一致；
• 有的团队在提交前需要跑性能基准测试，回归幅度超过阈值就阻断提交。

把这些差异都往内置工作流里堆，工作流会越来越臃肿，永远无法覆盖所有业务方。所以团队的下一步设计是：工作流的定义权下放到仓库级别，由最懂这个仓库业务的人来编写。

沿用工作台已有的"约定式发现"机制：

• Skill：在仓库的 .claude/skills/ 目录下放一个 SKILL.md，工作台打开仓库时自动识别、注册；
• MCP：在配置文件中声明 MCP 服务地址，工作台自动连接、暴露工具；
• 工作流：在仓库中按约定的目录结构和文件格式定义工作流，工作台打开仓库时自动发现并注册。

这套机制带来的关键变化：工作流的维护从"平台统一管控"变成"仓库自治"。每个仓库的工作流定义跟着代码走，版本可追溯、变更可评审、分支可隔离 —— 跟代码的管理方式完全一致。这是 GitOps 思维在 Agent Harness 上的延伸。

E · Skills × MCP：把「做什么」与「怎么执行」分离

到了这一层，工作台开始处理一个真正困难的问题：怎么让 Agent 既能复用通用能力，又能接入这个团队特有的内部系统，还要不让代码膨胀成一个谁都改不动的怪物。

这个团队的答案是把扩展能力切成两层：

• Skills ：声明 Agent「该做什么、按什么步骤做」 —— 是流程级的指南。
• MCP（Model Context Protocol）：暴露「怎么真正完成动作」 —— 是动作级的能力。

用一句更直白的话讲：Skills 是 Agent 的「大脑」，MCP 是 Agent 的「双手」。同一个 Skill 可以在不同环境调起完全不同的 MCP 实现；同一个 MCP 也可以被多个 Skill 复用，互不绑定。

为什么不只用 MCP？

这是这套架构最容易被误解的地方。MCP 已经能描述工具调用了，为什么还要搞一层 Skill？

答案是：MCP 描述的是「单步动作」，但工程世界里 80% 的有用任务是「多步动作的固定组合」。比如「做一次代码评审」其实是「拉 diff → 跑 lint → 比对规约 → 生成评审意见 → 写回评论」五步的固定组合。如果只有 MCP，Agent 每次都要从头规划这五步，既慢又不稳定。

把这个组合沉淀成一个 Skill，相当于把「靠模型规划」的部分硬编码成「靠流程驱动」。Agent 只需要决定「要不要触发这个 Skill」，剩下的步骤是确定的、可测试的、可被代码 review 的。

跨应用连接：让 Agent 能跨边界做事

一个 AI Native 工作台真正的杠杆，是能跨越一个个原本割裂的内部系统。这套工作台连接的几类典型应用：

• 研发协同：工单系统的工作项、需求、Bug；Code 平台的仓库、CR、提交。
• 设计协作：从设计稿读取标注与组件 token，自动生成对应代码骨架。
• 沟通系统：内部 IM 的群消息、机器人通知、@提醒。
• 仓库工具：本地文件系统、Git、构建工具、测试运行器。
• 其它：监控平台、知识库、日志聚合等。

每一个连接背后都是一个 MCP server。Agent 在执行任务时拼装的不再只是「调一个 API」，而是跨多个内部系统的复合动作：从工单读需求 → 从设计稿读视觉规格 → 在仓库里写代码 → 在 IM 里通知评审人。这是 Agent Harness 真正能撬动的杠杆点。

设计上最值得抄的点

• 「约定式发现」：Skill 和 MCP 都是按目录约定自动加载的，不需要在中心配置中心一项项注册。开发者新写一个 Skill，把文件放进 .claude/skills/ 就生效，跟 npm 的 node_modules、Webpack 的约定式路由是同一种工程哲学。
• 声明式 vs 命令式分层：Skill 是声明式的（描述要达成的状态），MCP 是命令式的（描述具体怎么做）。这跟 Kubernetes 的 Resource × Controller 模型异曲同工 —— 顶层声明不变，底层执行可换。
• 同一 Skill 多 MCP 实现：本机环境用 LocalShell MCP，云端环境用 SandboxShell MCP，Agent 不感知。这让 Skill 成为真正可复用的资产，而不是绑死在某一种部署形态上。

F · 知识管理：让 Agent 一点点变成团队老员工

这是整篇复盘里最容易被低估、但工程意义最深的一章。

很多团队在落地 AI Native 时都会撞到同一面墙：通用 Agent 写出来的东西看起来"像样"，但放到自己业务里就明显不对 —— 用错术语、调错内部接口、套了不属于自己的设计规约。原因不是模型不够强，而是模型不知道你这个团队的「团队隐式知识」。

问题：上下文困境

这个困境有三个表现：

1. 知识分散：业务规则、设计 token、数据字典、API 契约、流程惯例 —— 散落在文档、群聊、CR 评论、注释里，没有人能一次性给齐。
2. 知识规模过大：就算能聚齐，也塞不进单个会话上下文，硬塞还会让重要信息被淹没。
3. 知识时效性：业务在变、接口在改、人也在轮换，静态文档很快过期。

把上面三个问题合在一起就是：不是缺信息，而是缺「能在合适的时机、按合适的粒度、把合适的信息塞进去」的机制。

解题思路：渐进式贴近业务

团队没有一上来就建巨型知识库。而是采取了渐进式策略：

• 第一阶段：把高频的、跨业务通用的知识先沉淀（如代码风格、git workflow、术语词典）。
• 第二阶段：把单业务方有共性的流程沉淀（业务术语、模块结构、领域模型）。
• 第三阶段：把仓库级别、跟着代码版本走的强约束沉淀（API 契约、依赖图、关键模块的注释规约）。

每多一层，Agent 的输出就多一份「贴合业务」的味道。这不是一次性工程，而是持续运营的过程。

落地：分层 KBase + 渐进式披露

真正落地时，团队把知识库切成了三层：

• 全局层（团队知识库 / Global KBase）：所有业务方共享，比如代码风格、提交规约、通用术语。
• 业务层（业务知识库 / Business KBase）：按业务方组织，沉淀该业务方特有的流程、模型、约定。
• 仓库层（仓库知识库 / Repo KBase）：跟代码同生命周期，由代码作者维护，最贴近真实实现。

但分了层还不够 —— 知识塞太多依然会撑爆上下文。所以还做了一件关键事：渐进式披露（Progressive Disclosure）。

简单说就是：Agent 一开始只看到知识库的「目录」（标题 + 一句话摘要），不读全文；当它判断当前任务需要某一段时，再发起一次工具调用把这段全文读进上下文。这跟工程师查文档的过程一模一样 —— 没人会把整本手册都背下来才开始写代码。

这个机制带来的几个直接好处：

• 上下文窗口被精打细算地利用 —— 同样的预算能装下更多有用信息；
• 知识库可以做大 —— 不用担心"加一篇就变臃肿"；
• 调用过程是可观测的 —— 看 Agent 调用了哪些条目，就知道它到底参考了什么。

把上面这些拼到一起：分层 KBase + 渐进式披露 + 仓库内置知识 = 一个能持续学习、随业务进化、不会失控的团队记忆系统。

G · 八根支柱映射：这是一份完整的工业级 Harness

到这里我们已经把工作台拆得够细了。回到前六篇文章奠定的视角 —— Agent Harness 的「八根支柱」 —— 把这套工作台一支柱一支柱对照看，会得到一个相当完整的画面：

这张表里最值得停下来想一想的两件事：

1. 八根支柱是「同时」立起来的。一个工业级 Harness 不是先把会话做好再去搞工作流，而是这八件事必须并行推进、互相咬合。任何一根缺位，整个 Harness 就会显得「Demo 感」很强。
2. 评测（⑦）几乎是所有团队的弱项。能快速搞定「让 Agent 跑起来」，但很难回答「Agent 这版到底比上一版好多少、坏在哪」。这是接下来 6-12 个月真正区分团队水平的地方。

H · 可迁移到你团队的 7 个工程模式

不是每个团队都有这套规模做完整工作台。但这次复盘里有 7 个模式，哪怕只在自己团队里抄一两条都能立竿见影。按落地难度从低到高排：

1 ·「30 天魔咒」自检

给团队当前 AI 编码工具列一个清单，统计每个工具「上次有人正经用是什么时候」。如果 80% 都超过 30 天没人主动打开，问题不在工具数量，而在这些工具没有真正进入团队的工作回路。这是个免费但震撼的诊断。

2 · 把「会话」当成最小工作单元

不要再以「对话框」为主视图设计 AI 工具。把会话提升为带状态机、可列表化、可交接、可看板化的对象，UI 上像 Jira 工单一样组织它们。这一步会让 AI 工作从「散点尝试」变成「可管理的资产」。

3 · 双形态运行时（本机 + 云端）

从一开始就别把 Agent 绑死在用户笔记本上。云端运行时 + 本机运行时同时存在，会话可以在两边迁移。这让你能跑「夜间批量任务」、能让监控报警自动开会话，是把 AI 工具从工具升级到基础设施的关键一步。

4 · 把高频流程沉淀成内置工作流

盘点团队最高频的 3 条研发流程（通常就是「写需求 / 修 Bug / 查线上问题」），把它们的步骤画出来、固化成工作流，关键节点保留人审。不要追求「全自动」，追求「半自动 + 关键节点强校验」。

5 · Skills × MCP 的两层分离

就算暂时不上 MCP，也要在心里把「该做什么（Skill）」和「怎么做（动作）」拆开来设计。这种分层让你的提示工程从「一坨长 prompt」变成「可组合的小块」，维护成本会显著下降。

6 · 三层知识库 + 渐进式披露

建团队知识库时，强制分层：全局 / 业务 / 仓库。仓库层一定要跟着代码走（放进 .claude/ 之类的目录、纳入 PR 评审）。检索时只先给 Agent 目录摘要，让它按需取全文 —— 上下文窗口的使用效率会立刻提升一个数量级。

7 · 把工作流定义权下放到仓库

等团队对前 6 条都已经熟练后，把工作流也按「约定式发现」机制下放到仓库。每个仓库自己定义自己的流程，由 Code Owner 维护、纳入版本控制。这是把 Agent Harness 真正交到一线工程师手里的最后一跳。

关于这次复盘的最后一句话

这套工作台最有价值的地方不是某个具体功能，而是它呈现了一种工程心态：把 AI Native 当成一个需要长期运营的工程项目，而不是一个「集成几个模型 API」的产品需求。

八根支柱、三层知识库、双形态运行时、约定式扩展 —— 这些不是 AI 才独有的玩意，它们都是软件工程在过去三十年里反复证明过有效的设计原则，只不过这次的对象是 Agent。

所以从某种意义上讲，「AI Native 工作台」并不是一个新东西。它是把已经被验证过的工程范式，重新搬到了 Agent 这个新承载之上。这也是我对接下来三五年最乐观的一点：我们手里的工程经验，绝大部分仍然有效。