同步最新文档

2026-05-29 17:25:07 +08:00
parent 387fab8189
commit 383b678599
9 changed files with 137 additions and 1769 deletions
--- a/InBox/640.svg
+++ b/InBox/640.svg
--- a/InBox/AI-First产研团队的交付路径.md
+++ b/InBox/AI-First产研团队的交付路径.md
@@ -1,87 +0,0 @@
-# AI-First 产研团队的交付路径
-
-**来源：** [微信公众号 - 昀启AI+](https://mp.weixin.qq.com/s/dNLJagjAoHtiUJj_bc8k0g)
-**作者：** 昀启
-**日期：** 2026年4月21日 09:47
-**标签：** #AI-First #上下文工程 #Skill-as-Code #产研协作 #交付路径
-
---
-
-## 核心框架
-
- **指标**：AI 初稿准确率
- **底座**：上下文工程 (L0/L1/L2 三层收敛）
- **载体**：Skill-as-Code — 把团队规范和工作方法硬编码为可版本管理的工程资产
-
---
-
-## 初稿准确率是 AI 协作的前置变量
-
-> 为什么同样使用模型，不同团队的产出质量会出现显著差异？
-
-**差异的根源不在模型能力，而在于 AI 所获得的上下文质量。** 上下文充分且精准时，第一版初稿往往已接近可交付标准；上下文残缺或含混时，AI 的产出更像基于有限信息的推测，返工成本随之上升。
-
-**核心度量：** AI 生成的第一版初稿，有多大比例可以进入审查流程，或仅经少量调整后即可交付。
-
-这个指标直接关联 AI 协作的真实 ROI：
- 初稿准确率高 → 人的精力更多用在审查和决策上
- 初稿准确率低 → 人的精力持续消耗在返工和修补上
-
-很多团队引入 AI 后体感"快了但不稳"，本质上就是这个指标波动过大。
-
---
-
-## 六段式交付闭环：上下文逐级收敛与同步更新
-
-六个阶段的核心逻辑不是线性流程编排，而是**上下文逐级收敛、阶段持续校验、结果最终回写**。
-
-| 阶段 | 人的职责 | AI 的职责 | 显性资产（给人的） | 隐性上下文（给下阶段 AI 的） |
-|------|----------|-----------|-------------------|---------------------------|
-| 业务需求 | 定义目标、边界、优先级 | 起草需求内容 | 需求文档 | 业务意图、边界约束 |
-| PRD 设计（write-prd Skill） | 澄清歧义、确认范围 | 生成结构化 PRD | AI 可执行的 PRD | 功能目标、业务规则、验收标准 |
-| 技术方案设计（write-tech-design Skill） | 评审架构可行性 | 产出方案初稿 | 技术方案 + API 契约 | 模块边界、接口约定、架构约束 |
-| 任务拆解（breakdown-tasks Skill） | 确认优先级与依赖 | 拆解为可执行单元 | WBS 任务列表 | 单任务输入/输出/依赖/验收标准 |
-| Daily Coding Agent（编码/单测/CR Skill） | 审核关键逻辑与架构边界 | 编码→单测→CR→修复循环 | 经验证后可交付的代码 | 代码变更记录、新增接口与规则 |
-| 上下文更新（update-context Skill） | 审检沉淀结果 | 回写知识与上下文 | 更新后的知识资产 | 下一轮迭代的全量上下文基线 |
-
-**关键洞察**：注意"隐性上下文"这一列——需求阶段提供业务意图，PRD 阶段将意图转为结构化约束，技术方案阶段将约束收敛为技术决策，任务拆解阶段再将决策压缩为最小执行单元。到 Daily Coding Agent 阶段，AI 拿到的已不是一个模糊需求，而是一份高度收敛的任务上下文。
-
-最后一个阶段"上下文更新"负责闭合整个循环：代码变更后上下文同步刷新，确保下一轮迭代时 AI 的输入不会过时。
-
---
-
-## 上下文工程：知识库与分层加载
-
-### 系统知识库
-
-| 业务视角 | 技术视角 |
-|----------|----------|
-| 功能清单、业务流程、领域知识、状态规则 | 架构文档、数据模型、API 契约、技术规范 |
-
-两者之间通过**共享术语表**打通，确保 AI 在生成内容时，业务概念与技术实现使用同一套语义。
-
-> 知识库的完整度，直接决定了 AI 理解业务的深度，也决定了首稿在业务逻辑层面的可用程度。
-
-### 三层加载模型
- **L0（项目级）**：全局一致性
- **L1（文件级）**：局部适配
- **L2（任务级）**：单次任务准确率
-
-核心原则：**只在需要的时候给需要的信息。**
-
-### 上下文工程为什么应被视为组织级投入
-1. 决定了 AI 投入能否产生实际回报
-2. 是团队能力的沉淀载体（人员流动冲击减小）
-3. 具备复利效应——正向循环 vs 负向衰减
-
---
-
-## Skill 体系：上下文工程的可复用封装
-
-Skill-as-Code：把团队的工作方法与质量约束写成可版本管理的文本契约，而不是散落在聊天窗口里的一次性指令。
-
-文章中提到的 Skill 包括：
- `write-prd`：生成结构化 PRD
- `write-tech-design`：产出技术方案初稿
- `breakdown-tasks`：拆解为可执行单元
- `update-context`：回写知识与上下文
--- a/InBox/天猫AI编码实践四文对照整理.md
+++ b/InBox/天猫AI编码实践四文对照整理.md
@@ -1,182 +0,0 @@
-# 天猫 AI 编码实践四文对照整理
-
-## 原笔记引用
-
- [[天猫新品营销技术团队AI编码实战指南（上）]]
- [[天猫新品团队AI编码实战指南（下）]]
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]]
- [[AI-First产研团队的交付路径]]
-
---
-
-## 一句话结论
-
-这四篇文章虽然切入点不同，但核心结论高度一致：**AI 编码的上限，不主要取决于模型本身，而取决于团队能否把需求、规范、代码模式、领域知识、任务拆解和验证闭环，组织成 AI 可消费、可复用、可持续更新的工程资产。**
-
---
-
-## 共同点
-
-### 1. 都在反复强调：问题核心不是 prompt，而是上下文工程
-
- [[天猫新品营销技术团队AI编码实战指南（上）]] 强调，AI 写不对、写不好、写不了、改不动，根因大多来自隐性知识、需求模糊、任务复杂、缺少验证和工程结构问题。
- [[AI-First产研团队的交付路径]] 进一步把这件事抽象为“初稿准确率”问题，指出模型差异不是主要矛盾，上下文质量才是。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 则把上下文具体化成四层物料：开发规范、代码模式、领域知识、任务规格。
-
-共同认识是：**AI 不是因为不会写代码才失效，而是因为拿到的上下文不完整、不准确、不可执行。**
-
-### 2. 都主张“最大化复用”，而不是追求从零生成
-
- [[天猫新品营销技术团队AI编码实战指南（上）]] 把“最大化复用”列为核心方法论。
- [[天猫新品团队AI编码实战指南（下）]] 从代码复用、知识复用、工作流复用、工具复用、人机分工五个层级展开。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 进一步提出“能抄不写，能连不造，能复用不原创”，本质是让 AI 做胶水而不是原创主体。
-
-共识非常明确：**团队真正要建设的不是“更强提示词”，而是可复用的物料体系。**
-
-### 3. 都认为自然语言文档和结构化规格是核心输入接口
-
- [[天猫新品营销技术团队AI编码实战指南（上）]] 直接提出“自然语言第一”。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 用 `Task Spec` 承载当前需求意图。
- [[AI-First产研团队的交付路径]] 则把 PRD、技术方案、任务拆解都 Skill 化，形成逐级收敛的上下文链路。
- [[天猫新品团队AI编码实战指南（下）]] 还提出“视图分离”，把同一份 PRD 分成人读版和 AI 执行版。
-
-这说明：**文档不是代码的附属物，而是 AI 时代的软件输入层。**
-
-### 4. 都强调必须有验证闭环，不能把 AI 当黑盒执行器
-
- [[天猫新品营销技术团队AI编码实战指南（上）]] 明确要求补上 review、测试、前后端验证。
- [[AI-First产研团队的交付路径]] 把 Daily Coding Agent 定义成“编码→单测→CR→修复”的循环。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 的目标不是生成代码，而是提升生产可采纳率。
-
-共同点是：**衡量标准不是“写出来了”，而是“能否稳定进入交付流程”。**
-
-### 5. 都在把团队经验沉淀成可版本化资产
-
- `AGENTS.md`
- `spec.md`
- 样板代码
- 团队知识库
- Skill / 工作流脚本
- 上下文回写机制
-
-四篇文章都在做同一件事：**把本来只存在于熟手脑子里的隐性经验，外化为 AI 能稳定读取的长期资产。**
-
---
-
-## 关键差异
-
-### 1. 关注层级不同
-
- [[天猫新品营销技术团队AI编码实战指南（上）]] 更偏总论，解释为什么 AI 编码会失败，以及团队应如何补足工程基础设施。
- [[天猫新品团队AI编码实战指南（下）]] 更偏场景化落地，讨论不同业务严苛度下的人机分工与复用策略。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更聚焦中后台“胶水需求”的高采纳率打法。
- [[AI-First产研团队的交付路径]] 更像组织级方法论，强调交付链路、Skill-as-Code 和上下文持续回写。
-
-### 2. 对“AI 最适合做什么”的判断重心不同
-
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 最鲜明，认为 AI 最适合做“90%抄 + 10%写”的胶水型工作。
- [[天猫新品营销技术团队AI编码实战指南（上）]] 认为 AI 适合高复用、低歧义、边界清晰的 80% 工作。
- [[天猫新品团队AI编码实战指南（下）]] 则进一步按 C 端、B 端、小二端、工具端区分 AI 的适用边界。
- [[AI-First产研团队的交付路径]] 关注点不在某类代码，而在整个交付链是否能把任务收敛到 AI 可执行粒度。
-
-### 3. 物料结构的表达方式不同
-
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 是“四层物料体系”。
- [[AI-First产研团队的交付路径]] 是“L0/L1/L2 三层加载 + 六段式交付闭环”。
- [[天猫新品团队AI编码实战指南（下）]] 是“代码/知识/工作流/工具/人机分工”五级复用。
- [[天猫新品营销技术团队AI编码实战指南（上）]] 则是更通用的工程治理视角。
-
-虽然结构不同，但都在回答同一个问题：**该给 AI 什么信息、以什么时机给、给到什么粒度。**
-
-### 4. 适用对象和目标不同
-
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更像“如何提高业务出码采纳率”。
- [[AI-First产研团队的交付路径]] 更像“如何让整个产研团队围绕 AI 重组交付方式”。
- [[天猫新品团队AI编码实战指南（下）]] 更像“不同业务场景应该怎么设计 AI 工作流”。
- [[天猫新品营销技术团队AI编码实战指南（上）]] 更像“AI 编码问题诊断与总策略”。
-
---
-
-## 可以合并出的统一框架
-
-如果把四篇文章压缩成一套统一模型，大致可以整理成下面这条链路：
-
-1. **先显式化需求**
-   把模糊业务目标转成结构化需求、边界、验收标准。
-
-2. **再补齐静态底座**
-   提前准备 `AGENTS.md`、代码规范、样板代码、领域术语表、知识库索引。
-
-3. **按任务粒度动态加载上下文**
-   不全量塞资料，而是按项目级、文件级、任务级逐层注入。
-
-4. **优先让 AI 做复用型工作**
-   组件拼装、页面搭建、CRUD、接口对接、样板代码延展、文档生成。
-
-5. **复杂任务拆黑盒**
-   把大任务拆成边界清晰、可独立验证的小任务，降低“改不动”的概率。
-
-6. **以验证闭环替代一次生成幻想**
-   编码、单测、CR、修复、回写知识，形成迭代闭环。
-
-7. **把过程沉淀为下一轮资产**
-   当前需求完成后，不只交代码，还更新 spec、知识库、样板和工作流。
-
-这条链路本质上就是：**显式化 -> 结构化 -> 复用化 -> 校验化 -> 资产化。**
-
---
-
-## 最值得吸收的几个强观点
-
-### 1. AI 编码的 ROI 关键指标不是速度，而是“初稿准确率 / 采纳率”
-
- [[AI-First产研团队的交付路径]] 强调初稿准确率。
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 直接用采纳率来证明方法有效。
-
-这比“生成了多少代码”更接近真实业务价值。
-
-### 2. 关键规则必须静态在场，不能赌 AI 主动查文档
-
-这个观点在 [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 里特别尖锐：如果规范只放在可检索文档中，AI 可能根本不会主动去看；关键约束应该放进 `AGENTS.md` 或类似的强注入入口。
-
-### 3. 好的 AI 协作不是减少文档，而是提高文档的执行性
-
-四篇文章都在证明，AI 时代不是“不写文档”，而是要写**更能驱动执行的文档**：
-
- 人看得懂
- AI 也能直接消费
- 能版本管理
- 能逐轮更新
-
-### 4. AI 更像高效但不稳定的执行者，不是自动化替代品
-
-这也是四篇文章最一致的现实主义立场：**不要神化模型，要工程化地驯化模型。**
-
---
-
-## 对我自己的可落地启发
-
-### 适合立即做的事
-
- 给常做任务建立固定 spec 模板。
- 把仓库中的关键规范上提到 `AGENTS.md` 或固定入口。
- 为高频页面/模块准备“样板代码”而不是只写原则。
- 把易踩坑知识整理成可检索知识库，而不是散落在聊天记录里。
- 每次做完需求后，回写实现经验，让下一次不是从零开始。
-
-### 需要避免的误区
-
- 只优化 prompt，不治理仓库结构。
- 把复杂需求整包扔给 AI，不做任务拆分。
- 以“生成速度”代替“可采纳质量”。
- 希望 AI 从零原创一切，而不是基于现有资产复用。
- 做完代码后不回写知识，导致上下文长期失真。
-
---
-
-## 适合作为总纲的理解
-
-如果只保留一句总纲，可以是：
-
-> **AI 编码不是“让模型替你开发”，而是“把团队的需求表达、代码模式、知识经验和验证流程，重构成模型可稳定执行的交付系统”。**
-
--- a/InBox/天猫新品团队AI编码实战指南（下）.md
+++ b/InBox/天猫新品团队AI编码实战指南（下）.md
@@ -1,78 +0,0 @@
-# 天猫新品团队AI编码实战指南（下）
-
-**来源：** [微信公众号 - 大淘宝技术](https://mp.weixin.qq.com/s/iRkxznDYhE-kXjbIHlrnNA)
-**作者：** 天猫新品营销技术
-**日期：** 2026年5月8日 16:07
-**标签：** #AI编码 #天猫 #全栈化 #知识库 #实战指南
-
---
-
-## 背景
-
-团队开始了后端向前，前端向后的全栈化转型运动。后端承担小二工作台与研发工具开发（需求驱动型），前端承担 C 端 solution 编写。
-
-**核心思想：** 作为业务团队，重点应该是沉淀自己团队的工作流与 AI 资产——通过**最大化复用**来提高整体效能（代码、知识、工作流、工具的复用）。
-
-### 场景分类
-
-| 严苛程度 | 典型场景 | 错误容忍 | 交互问题容忍 | 代码要求 | 视觉还原要求 |
-|----------|---------|---------|-------------|---------|-------------|
-| 最为严苛 | C 端频道 | 0 容忍 | 明显则 0 容忍 | 高 | 高 |
-| 较为严苛 | B 端商家平台 | 0 容忍 | 特别明显则 0 容忍 | 中 | 中 |
-| **交付分割线** | | | | | |
-| 普通严苛 | 小二端工作台 | 0 容忍 | 影响主链路则 0 容忍 | 低 | 低 |
-| 低严苛 | 研发自用工具 | 一定程度容忍 | 无 hack 绕过则 0 容忍 | 无 | 无 |
-| 不严苛 | 研发 DEMO | 能意会则容忍 | 怎么都能容忍 | 无 | 无 |
-
---
-
-## 小二端 - AI 主导的对话生码
-
-特点：无视觉还原要求，实现形式自由，页面独立性强，适合 AI 编码完成全部需求。
-
-### 初期 - 统一生成方案
- 提供标准化的代码规范与视觉规范文档
- 提供高度封装的代码模版（一行代码唤起页面组件）
-
-### 中期 - 辅助补齐前端经验短板
- **需求描述不准确**：搭建「AI案例实践中心」，标准化 prompt 模板；提供 MCP 速查工具「天猫新品业务编码助手」
- **垂类场景无经验**：将 AI 生码省下的时间用于生码沉淀，详细记录实现过程与踩坑心得
-
-### 后期 - 更简单、无感、一致的方案
- 开发轻量级团队知识库，以类 Skill 形式封装开发规范与代码模板
- 知识库用 git 仓库管理，npm 包作为资源承载与版本管理工具
-
---
-
-## C 端 - 交付质量要求的 AI 提效
-
-C 端场景复用机制复用分为五个级别：
-1. **代码复用**：对组件、布局、逻辑进行封装（RCG——布局/组件/脚手架粒度递进）
-2. **知识复用**：团队知识库 + 逐层加载
-3. **工作流复用**：固定 AI 工作流 + 兜底方案
-4. **工具复用**：通过 MCP 协议 + 内部工具获取业务数据
-5. **人机分工**：固定重复工作交 AI，关键环节人把控
-
-### 视图分离方案
-
-**核心思想：** 把一份 PRD 分成"给 AI 的结构化描述"和"给人看的说明文档"，各自优化。
-
- 在 C 端，过复杂的 prompt 和过长的上下文都会带来性能问题
- 提出了结构化的 prompt 写法，包含场景分析、关键数据、交互与动效说明
-
-### 知识库建设
-
-对标 OpenAI 的 `prompt.md` + `--preamble` 的标准化管理：
-1. 定义优先级规则
-2. 使用 script 进行文件注入（含自动 chunk、优先命中机制）
-3. 统一文件结构和索引
-
---
-
-## 实用技巧集锦
-
- **UI 重构**：利用 prompt 对图片转结构化描述
- **复杂 Prompt 构建**：结构化多段式
- **多方案选优**：让 AI 给出多个方案并对比
- **文档生成**：代码完成后自动生成说明文档
- **严厉语气 + 合理质疑**：实验表明严厉语气能提升准确率
--- a/InBox/天猫新品营销技术团队AI编码实战指南（上）.md
+++ b/InBox/天猫新品营销技术团队AI编码实战指南（上）.md
@@ -1,30 +0,0 @@
-# 《天猫新品营销技术团队AI编码实战指南（上）》
-
-**来源：** [微信公众号文章](https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650543356&idx=1&sn=c460ef2f9e36ffbdc1083dd36c2595b6)  
-**本地存档：** `C:\Users\Zane\Desktop\我的\天猫新品营销技术团队AI编码实战指南（上）.html`  
-**作者：** 天猫新品营销技术  
-**标签：** #微信文章 #AI编码 #工程实践 #团队方法论
-
-## 重新总结
-
-这篇上篇文章的核心判断是：AI 编码已经能显著提效，但真正的问题不在“模型会不会写代码”，而在“团队能不能把需求、上下文、工程结构和校验流程组织成 AI 可稳定执行的形态”。作者基于天猫新品团队实践，把 AI 编码常见失败归纳为四类：写不对、写不好、写不了、改不动；再把根因拆到项目知识缺失、用户输入模糊、任务复杂度过高、缺少自检闭环、模型和 Agent 能力边界这五个维度。
-
-文章给出的主线不是追求一次性完美生成，而是通过工程化手段提升“前 80% 的成功率”和“后 20% 的收敛效率”。对应的方法论有三条：最大化复用、自然语言第一、接受二八定律。最大化复用强调把系统拆成可理解、可调用、可组合的模块和工作流，尽量让 AI 做胶水代码而不是重造轮子；自然语言第一强调文档、规范、需求说明和过程记录要先于代码，文档质量直接决定 AI 产出质量；二八定律则提醒团队接受 AI 在 0% 到 80% 阶段很快，但在复杂收尾、边界修复、旧逻辑耦合阶段会明显失速，因此需要人为介入和流程补强。
-
-在执行层面，文章按完整流程给出优化建议：开发前先准备知识库、AGENTS/README、代码规范、目录边界和可检索上下文；需求阶段把模糊 PRD 转成更明确的功能描述，必要时引入 spec 化文档；任务设计上降低复杂度，把大任务拆成可验收的小黑盒；开发中持续维护过程文档和上下文，避免 AI 因窗口限制失焦；完成后补上 code review、测试、前后端验证等自检环节。作者尤其强调，很多 AI 编码问题本质上不是“提示词技巧”问题，而是仓库结构差、耦合重、文档缺、验证弱导致的工程问题。
-
-文章最后通过场景分类说明实践差异：一类是“需求驱动型”，重点在让 AI 准确理解业务目标和验收标准；另一类是“工程主导型”，重点在模块边界、复用能力、视图分离、知识沉淀和工作流建设。整体结论很务实：不要把 AI 当成能脱离工程体系独立完成软件开发的黑盒，而应把它纳入团队的文档、规范、测试、知识库和流程体系中，作为一个高效但不稳定的执行者来管理。
-
-## 核心要点
-
- 四大痛点：写不对、写不好、写不了、改不动。
- 五类根因：项目隐性知识太多、需求输入不清晰、任务复杂度过高、缺少 review/test 闭环、模型与 Agent 有天然边界。
- 三条方法论：最大化复用、自然语言第一、接受二八定律。
- 真正的提效点不是“多写 prompt”，而是把需求、文档、知识库、模块边界和测试流程变成 AI 可消费的上下文。
- 复杂项目里，AI 更适合完成高复用、低歧义、边界清晰的 80% 工作；剩余 20% 仍需要工程治理和人工兜底。
-
-## 对我的启发
-
- AI 编码的上限，更多取决于仓库可读性、知识显式化程度和验证手段，而不是单次对话技巧。
- `AGENTS.md`、README、Spec、CodeWiki 这类文档不是附属物，而是 AI 开发链路里的输入接口。
- 如果一个需求总是“改不动”，优先怀疑任务拆分、模块耦合和上下文组织方式，而不是只怪模型笨。
--- a/InBox/清华大学驾驭工程
+++ b/InBox/清华大学驾驭工程
@@ -1,475 +0,0 @@
-# 清华大学：驾驭工程 (Harness Engineering) 研究报告
-
-> 来源：GIS极客 · 微信公众号
-> 日期：2026年4月10日
-> 原文：https://mp.weixin.qq.com/s/EdVjZuBVcXjd30TpxyLsXQ
-> 完整报告下载：关注公众号 **GIS极客**，后台回复 **"清华HarnessEngineering"** 获取下载链接
-
-Visual: [[清华大学 驾驭工程 Harness Engineering 研究报告.visual]]
-
---
-
-## 提取说明
-
-这次按“每张图 = 一个模块”重组。
-
- 图片已下载到 `清华大学 驾驭工程 Harness Engineering 研究报告.hires/`
- 每个小节对应一张原图
- 小节标题优先按图片主标题人工整理
- 正文尽量保留 OCR 全文，只做了轻度空格清洗
-
-风险：
-
- OCR 对英文、链接、少数专有名词和局部排版仍有误识别
- 个别页图像里有示意图、图标或多栏布局，转写会比纯段落页更差
- 如需完全准确版本，仍应以对应原图为准
-
---
-
-### 驾驭工程（Harness Engineering）研究报告
-
-页码：`page-01.jpg`
-
-驾驭工程 (Harness Engineering) 研究报告一下 0 乁《电脑日志面板 Agent 核心判断：驾驭工程是操作系统层提示词工程是语言层智能体工程是工作流层；驾驭工程是操作系统层。对象：高自治、长时程、可治理的 A 係统丨 26 年 26
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-01.jpg]]
-
---
-
-### 清新研究团队简介
-
-页码：`page-02.jpg`
-
-· 领导学术研究团队近 30 人。指导大数据、 AI 、人形机器人等多个产业团队。冫目视频号： @清新研究；公众号： @清新研究九 | 司月沈阳：清华大学新闻学院 / 人工智能学院双聘教授、博导 · 团队坚持：整体主义、实证主义、社会建构、进步主义。 " 六大研究方向： 。 ？ 1 ． A 吠模型理论与哲学 4 · 新媒体与网络舆论网邮箱： 124739259@q q ℃ om 圈 oo 囗囹 00 囗 2 · AI 文艺回。 ． 回回 ． 回回彗 3 ． A | 应用 6 ． × R 应用丨微博： @ 清新研究 | 公众号： @ 清新研究
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-02.jpg]]
-
---
-
-### 全文结构目录
-
-页码：`page-03.jpg`
-
-全文结构目录术语状态 ． 从术语状态 ． “ ． ，按“定义一证据一结构一落地”展开。结构 · 四层链条到 ． “ · 它和提示词 / 上下刘智能体工程的边界是什么证据。第一部分回答“ · 。这个词现在是什么落地 · 中国落地路线 ． “ · 按“定义一证据一结构一落地”展开。 @ 清新研究团队 | 2026 年 3 月 2
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-03.jpg]]
-
---
-
-### 一句话结论
-
-页码：`page-04.jpg`
-
-一句话结论总判断驾驭工程不是把提示词再写长一点，而是把模型周围整个制度化执行环境设计出来 0 怎么让型动起来怎么说清 0 一模型提示词工程 - 智能体工程程制杂“提示词工程解决“怎么说清楚” 0 。智能体工程解决“怎么让模型动起来” 0 @ 淆究团队《 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-04.jpg]]
-
---
-
-### 四层链条：从语言到操作系统
-
-页码：`page-05.jpg`
-
-四层链条：从语言到操作系统驾驭工程核心观点提示词工程、上下文工程、智能体工程、骘驭工訴一互斥关系，而曰层上语言层关注指令表达，上下文层关注状态供给 > 上下文层语言层智能体工程关注状态供给关注指令表达 @ 清新研究团队 | 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-05.jpg]]
-
---
-
-### 第一部分：术语状态
-
-页码：`page-06.jpg`
-
-第一部分 | 术语状态葳至 2026 ． 03 一 26 、 、 、 、 \ 术语状态冫当前术语体系基本稳定，关键定义待进一步明确。 @ 清新研团队 | 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-06.jpg]]
-
---
-
-### 它不是教科书术语，但已被前沿团队反复使用
-
-页码：`page-07.jpg`
-
-它不是教科书术语，但已被前沿团队反复使用术语状态 H4R § S 卪 48 q ： 2026 ． 02m OpenAl 在 2026 ． 02 · 11 明确使用 harness en.. 这说明它已进入一线工程实践话语。早些时候近期、 、 、 、 、 、 、乛工程博客时间轴但它仍在形成中，边界尚未像“数抿库”或“擞。服务”那样冻结。 0 边界仍在探索和定义中。数据库徼服务歡櫷源： https濯0些na靴om／刑e对ha賺翰e哣谳丽g/ ； httpsflwww.anthtopic.com/engineering/effective-harnesses-for-lcng-running-agents ； https//www.arthropic.wm!engineering/harness-design-lcng-running•apps
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-07.jpg]]
-
---
-
-### OpenAI 为什么叫它 Harness Engineering
-
-页码：`page-08.jpg`
-
-OpenAI 为什么叫它 Harness Engineering OpenAI 证据五个月后仓库达到约百万行 0 仃人工代码启动 OpenAI Codex 实验场景 HARNESS 估算开发时间 0 ENGINEERING 约为手写的 1 / 10 ． 丿 OpenAI 的核心变化是：工程师的主业不再是手写代码代码库
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-08.jpg]]
-
---
-
-### Anthropic 为什么持续谈 Harness
-
-页码：`page-09.jpg`
-
-Anthropic 为什么持续谈 Harness Anthropic 证据一亠一亠 Anthropic 的实践把 harness 从抽象口号压成 2025 · 11 的文章聚焦长时程会话，@@鄱 2026 · 03 的文章把 harness design 推到长时程“祀一数据源： https://mvw anthropic.com/engineering/effective-harnesses-for- long-running-agents ： https://www anthropic.com/engineering/harness-design-long-running-apps
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-09.jpg]]
-
---
-
-### 为什么“现在”突然重要
-
-页码：`page-10.jpg`
-
-7 回答问丿聊天气泡因为模型已跨过“回答问题”的门槛为什么“现在”突然重要 · OpenAI 己把 agents 定义为能完成从简单目标到开放式完成开放式任务 ． 工作台 · Anthropic 区分 workfl ow 一 agent ． 数据来源： https:!/developers.openai.com/api/docs/guides/agents ； https://www.anthropic.com/engineering/building-effective-agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-10.jpg]]
-
---
-
-### 瓶颈已经从“生成更多”转向“让人只在高杠杆节点出手”
-
-页码：`page-11.jpg`
-
-瓶颈已经从“生成更多”转向“让人只在高杠杆节点出手”瓶颈变化 1 优先级判断节点出手代码吞吐 (Code Throughput) OpenAI 公开写道，随着代码吞吐上升，瓶颈变成了 human QA• 这意味着系统设计的目标不再是“让多做点” 2 · 3 0 LOW SCARCE 人类注意力 (Human Attention) EXECUTIVE SUMMARY HUMAN QA BOTTLENECK 关踺高杠杆节点
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-11.jpg]]
-
---
-
-### 中国落地窗口已经形成
-
-页码：`page-12.jpg`
-
-中国落地窗口已经形成 10 ％ 介 1408 亿元数字经济体量与增长 2024 年数字经济核心产业增加 11 。 08 亿人川 24 年我国同民換 / ／ ' | 人工智能 + 未来驱动引擎互联网昔及率、网络规模与普及率。中国政策、网络规模与数字经济体量力数源智龍应用础彘施体生膚 0 过 · 2024 年数字经济核心产业增加值 140891 亿元。 2024 年我国网民规模 11 ． 08 亿人，互联网普及率 78 ． 6 ％ 蟲樾睾：卜 ttpc / 艹虱“ / 。伍 2St2n 却 25 旧 0 ． 四 62m htA ；卜 t 丿 / “ “ “ 《 “伍。 ti ' 丿闸。叫 /VS 馴 34 117 四 ． 恒靼刀 - “ ， m “彐“ ' n ／ 於 ． “ 6 / - 加“ ． 3 / 20 理 ms3103 仆。 。 。 / 心 03 02 312 ． n8 ht
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-12.jpg]]
-
---
-
-### 第二部分：四层链条
-
-页码：`page-13.jpg`
-
-02 第二部分丨四层链条先厘清层级边界，才能避免把所有能力混叫成噁严《四、自主 (Autonomy) 、协作 b “薹础词 @ 清新研究团队丨 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-13.jpg]]
-
---
-
-### 提示词工程：语言层
-
-页码：`page-14.jpg`
-
-0 提示词工程：语言层提示词工程定义 · OpenAl 仍把 prompt engineering 定义为 ． 它解决的是“怎么说清楚” · 重点包括角色设定、输出格式、上法、示例组织一臼令优先级指令纸（ SYSTEM PROMPT) 、系统提示 (SYSTEM PROMPT) 色设定 ． 你是一个专业的 A 勵手 ． · 上下给法：基于以下信息“格式约束 (FORMAT CONSTRAINTS) 出格。请使用 Markdowm 指先级：请优先执行， ． 示例组织 EXAM PLES ）示 1 ：用户输入“ ， A | 输出“示例 2 ：丿 0 数据来源： https://developers.openai.com/api/dcxs/guides/prompt-engineering ； https://developers.openai.com/api/docs/guides/prompt-engineering
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-14.jpg]]
-
---
-
-### 提示词工程的能力边界
-
-页码：`page-15.jpg`
-
-提示词工程的能力边界提示词工程边界（单轮任务） g 单轮生成 0 结构化输出 0 风格一致性和清晰遵循验收（刀当任务是短时、闭环、单步可验收时，提示词工程往往已经够用。很多团队在这里就能拿到很高 ROI ，不需要急着上 Agent0 数扼来源： https://developersopenai.com/api/docs/guides/prompt-engineering ， https://wwwnnthropic.com/engineering/building-effective-agents 复杂长时程任务（挑战与限制）严 2 @ 多步推理与起忆 × ？外部工具交互 × × @ 动态环境适应外部数据错反馈面临长时程、多目标、需持续交互的任务时，单纯提示词工程能力不足，需要引入 Agent 等更复杂系统。
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-15.jpg]]
-
---
-
-### GPT-5.4 之后，提示词重点被推向“契约化”
-
-页码：`page-16.jpg`
-
-GPT-5.4 之后，提示词重点被推向“契约化”提示工升 ． OpenAl 最新指导把高杠杆提示尹词变化概括为 output cont•• ． 这说明提示词工程并没有消失，而是在向可执行契约演化。 。提示词不再只是“写得像人”而是开始承担流程控制语义 0 數抿耒源： https://developers.openai.com/api/docs/guides/prompt-guidance/ 0 目标状态孑终止信号 S\JCCESS \ 具体的准确度数完成条件凵逻辑约刺 (Completion Conditions) nput/output protocol, 工具期待 (TOOI Expectations) database and interfaces JSON 」 5 4 function calls with ／ 咿 predefined parameters 输出契约 (Output Contracts) Fixed output format Fixed output format
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-16.jpg]]
-
---
-
-### 规划、前导语与过程可见性
-
-页码：`page-17.jpg`
-
-PLAN 0 0 计划 MILESTONE 确定目标与步驟规划、前导语与过程可见性工具前导语工具系统区分指息 0 前导语 PREAMBL OpenAl 针对 agentic tasks 强调：对长时或重工具流程 ． preamble 让模型在调用工具前说清意图。工具调用 TOOL CALLS 0 执行操作，与外部系统交互阶段更新 PHASE UPDATES phase 则帮助系统区分中间 commentary 与 fina. 完成 COMPLETE 达到预期鲒果数塘源： https://dwelopers.openaicom/api/docs/guides/prompt-guidance/ ；
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-17.jpg]]
-
---
-
-### 隐藏中间层：上下文工程
-
-页码：`page-18.jpg`
-
-03 隐藏中间层《上下文工程如果提示词工程管“说什么” ，上下文工程就管“喂什么”管“说什么”提示词工程 @ 清澌研究团队丨 2026 年 3 月 26 日 Context Engineering 管“喂什么” 0 0 、 0 上下文工程
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-18.jpg]]
-
---
-
-### 上下文工程：隐形内核
-
-页码：`page-19.jpg`
-
-上下文工程：隐形内核上下文工程定义睾 Anthropic 明确把 context engineering 视核心问题不再只是 system p rom pt · 它包括系统指令、工具、外部数据、消息历史、 MCP 、长期状态等。外部数据消息历史上下文状态球体 0 提示 MCP 长期状态数据来源： https://www.anthropic.com/enqineerinq/effective—context—enqineerinq—for-ai-aqents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-19.jpg]]
-
---
-
-### 上下文是关键但有限的资源
-
-页码：`page-20.jpg`
-
-上下文是关键但有限的资源上下文有限搋挤 0 0 上下文物理边界上下文窗囗不是抽象参数，而是 Agent 能否保持一致行为的物理边界。 02k / 128k USED 上下文预算占用情况任务本身关键约束 ． ，上下文一旦拥挤，任务本身、关键约束和新证据就会互相争枪注龜力。 。 ` Anthropic: 、 。 。长时代理策略 Anthropic 直接指出：长时代理需要不断展与压上下文。不断策展信息筛选压缩上下文立净内存数据来源： https://www、*
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-20.jpg]]
-
---
-
-### 上下文状态由什么组成
-
-页码：`page-21.jpg`
-
-上下文状态由什么组成上下文状态组成系统指令定义高优先级规则。孑历史回@ 完整的交互记录。 0 工具决定模型看见哪些动作可能性。摘要精炼的关键信息。 ？乙 ． 外部数据提供世界知识。长期状态持久记忆与个性化。 O 蚴模型入 ． 0 一动作 ／ 响应在多轮代理里，真正进入模型判断的不只是聊天记录。数来源： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-21.jpg]]
-
---
-
-### 为什么上下文会“腐烂”
-
-页码：`page-22.jpg`
-
-为什么上下文会“腐烂”么卧上下文腐烂一， vs 、 ． 一上下文腐烂是今明确目新鮮。越长的会话越容易出现辶状态漂移、通漏、过时规则残留和局部模式俣旧指令可能遮蔽新目标。冗长历史会让穫型把局部线索误当全局事实。 。越长的会话越容易出现状态漂移、違、过时规则残留和局聾式课。旧指令可能遮蔽新目标。 。冗长历史会让樓型把局部线索误当全局事实。随着时间推移，上下文质量下降 @ 数握来源： htfps ： //wwwnnthr叩ic.com/engineering/effective-context-engineering-for-ai-agents 乜时“腐对上下
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-22.jpg]]
-
---
-
-### 上下文工程是内核，驾驭工程是外壳
-
-页码：`page-23.jpg`
-
-上下文工程是内核驾驭工程是外壳飞上下文与 Harness 区别 · 我的判断是： context engineering 管“喂给模型什么” · 前者解决状态供绐。 · 后者解决状态之外的契约、权限、回滚、审计和熵控内核与操作系统外壳的分层图外郜交互与訾控外壳驾驭工契约与奴限外部交互与管筏回与版本控制、数与状态流向模型 ／ 管蛤摟型什么”解决状共蛤《 0 》审计与监 \ 崆制与隐足性内核 (Core) ：上下文工程 (Context Engineering) 知 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-23.jpg]]
-
---
-
-### 第三部分：智能体工程过渡
-
-页码：`page-24.jpg`
-
-第三部分刂智倻工智能体工程过渡当模型开始带工具、多轮行动并动态选择路径，问题就从“ " 变成“工作流 " 任分稱 0 划，皿、丿司动态选径工作流 @ 清新研究团队丨 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-24.jpg]]
-
---
-
-### 智能体工程：工作流
-
-页码：`page-25.jpg`
-
-智能体工程 0 工作流智能体工程定义工作流画布一， Guardrails 安全护栏记忆 / 知识。 OpenAI 把 agents 定义为能从简单目标走到复杂开放式工作流“ · 智能体工程的关注点是让模型动起来。其核心对象包括模型、工具、记忆 / 知识、 guardrails 、控制流“控制流数据源： https://developers.openai.com/api!docs/guides/agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-25.jpg]]
-
---
-
-### Anthropic：Workflow 与 Agent 不是一回事
-
-页码：`page-26.jpg`
-
-Anthropic: Workflow 与 Agent 不是一回事 workflow vs agent Workflow （预定义代码路径） Anthropic 的区分非常关键： workflow 走预定义代码路径 ' 前者更可预测。定性流程图 (Deterministic Flowchart) Sturt Step 1 0 1 ） dition Step 2 2 ） No Step 3 （步 0 3 ） End （ ）数据来源： Agent （动态决策路径）后者更灵活，也更难验证和治理。 Decision? Environment 惭境）动态决路径 (Dynamic Decision path) https://www anthropic.com/enginæring/building-effective-agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-26.jpg]]
-
---
-
-### OpenAI Agent 架构的六个要件
-
-页码：`page-27.jpg`
-
-OpenAI Agent 架构的六个要件 Agent 架构 Agent 不是只有模型这说明 agent eng i neering 已经是一套系统工程。单个模型再强，也需要被放进工作流与保护层。模型 LLM/Core APIs/Functions 0 ） guardrails Safet /Poli 知识 Memo /Retrieval 逻辑 Reasonin Plcnni 评测 Evaluation/Testing 数据来源： https://developers.openai.com/api/docs/guides/agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-27.jpg]]
-
---
-
-### 工具不是 API 包装，而是给 Agent 的动作契约
-
-页码：`page-28.jpg`
-
-》 ／ 侄具不是 API 包装，而是给 Agent 的动作契约工具设计工具面板 / ' · Anthropic 反复强调 ． 动作契约 0 ， 0 ' ； 00@夢 0 工具需要被当成“给非确 0 - AgenV (Action Contract) 0 丰富信返回上下文理纭采 (Return Context) Token 效率优化输入输出，节省成本工具描述准确指引，明确能力定性代理看的软件契纟勺 " 来设计。 · 名字空间、返回上下文、 token 效率与工具描述都会影响表现。亻囫 0 数源 ． https://www.anthropicxom/engineering/writing-tools-for-agents@
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-28.jpg]]
-
---
-
-### 为什么工具层开始从“直接调用”转向“写代码调用”
-
-页码：`page-29.jpg`
-
-为什么工具层开始从“直接调用”转向“写代码调用” MCP 与代码执行 0 ． Anthropic 在 MCP 文章中指出，直接工具调用会消耗上下文； 。 Agent 可以通过代码把复杂任务分解为更经济的执行路径。 0 工具定义 0 更强代理代码执行 MCP (Model Context ProtocoI) 核心价值艹厂囗囗囗复杂任务分解精确检索与执行数扌居 ． 源： https ： //www anthropic.com/engineering/code-execution-with-mcp
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-29.jpg]]
-
---
-
-### 没有 eval 的 Agent，只是会行动的黑箱
-
-页码：`page-30.jpg`
-
-没有 eval 的 Agent, 只是会行动的黑箱评测回路 | 身 Anthropic 在 eval 文章中强调匚 / 单轮。 “吧不足以覆盖长时代囗囗理 grader 生产监控、自动评测、 B 、人工审阅要形成多层防线。任务一反馈。代理 0 数来： https:hwww.anthropic.com/engineering/demystifying-evals-for-a卜agents 、一二《 《 《 《一一
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-30.jpg]]
-
---
-
-### 第四部分：制度层
-
-页码：`page-31.jpg`
-
-4 制度层当提示、上下文、工作流都不够解释问题时，剩下的就是制度层。 @ 清新研究团队丨 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-31.jpg]]
-
---
-
-### 驾驭工程的严格定义
-
-页码：`page-32.jpg`
-
-驾驭工程的严格定义契约工具验证严格定义标契约高自治 AI 模犁记忆安全舒围绕高自治 AI 构建整套可持续执行环境一目标契约了@ ， ， ． 一一， 。目标不是让模型“会做事” 。它是系统级环境设计，而不是单点技巧集合。 x 、一一，一一 ． 一一一一二一一一一一一 ． 一 @清新研究团队 | 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-32.jpg]]
-
---
-
-### 为什么我把它定义为“操作系统层”
-
-页码：`page-33.jpg`
-
-为什么我把它定义为“操作系统层” 0 为什么是 OS 层 Agenth 统架构户愉入只是输入接囗操作系统分层图： Agent 世界对照因为它不只决定一次输出，而是决定任务如何被启动语言层只是输人接口。工作流层只是动作编排。工作流排作盈引操作系统层（ OS 层）核心：决宸任芳如何被启动只是动作苤悱因为它不只决定一次輸出任务划权督理状记亿存实时监窪 A nt 执行与环境传操作系 OS 用户应用层 Shell/APlä 核 (OSE) 文件系統 / 调度件夤膊层 Agent 世界 OS 用户指令 / 应用 - 语盲 / 工作流口 OS 层 (Agent OS) 任身观划与拽行能力与衩记亿与状态訾理行力监与安全执环境与工具 @ 新研壳团队 | 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-33.jpg]]
-
---
-
-### 它不是替代提示词工程，而是对它的上卷
-
-页码：`page-34.jpg`
-
-它不是替代提示词工程，而是对它的上卷，不是替代关和而是对它的上卷驾驭工程 Age nt Prompt ． ResuIt 〕 Context Prompt · 因此 "prom 死”这种说法并不成立。 ． 真正的变化曰 rompt 不再是全部，驾驭工程把 prompt 、 context 、 agent 而刂度层中的一个部亻。全部吸纳进去清新研究团队丨 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-34.jpg]]
-
---
-
-### 六个负重部件总览
-
-页码：`page-35.jpg`
-
-六个负重部件六大负重部件总览本报告把驾驭工程拆成六个必须被工程化的负重部件。 1 ． 机器可验证的完成契约 CONTRACT g-O · 机器可验证的完成契约。 4 ． [Component 4 Name] · [Brief description Of component 4 ] 2 ． DurabIe KnowIedge 的 System of Record 0 REC · durable knowledge 的 system Of rec•• 5 ． CComponent 5 Name] · [Brief description Of component 5 〕 @ 清新研究团队丨 2026 年 3 月 26 日 3 、 [Component 3 Name] 0 · [Brief description Of component 3 ] 6 ． [Component 6 Name] · [Brief description Of component 6 〕
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-35.jpg]]
-
---
-
-### 部件一：完成定义必须可机器验证
-
-页码：`page-36.jpg`
-
-部件一：完成定义必须可机器验证 0 完陇契约清单 .Com letion Contract Checklist) 团队原创定义 0@ 1 ． 输出格 (Output Format) 一预定数据结掏与相式范 2 ． 工具使用仃 00 | Usage) 一指定工具调用与交互流程 3 ． 停止条件 (Stopping Conditions) 一明确终止触发与边界倩况 4 ． 验收方法 (Acceptance Methods) 一自动化测试与正准则 〕 SON ERROR 。 OpenAl 的提示指导和 Codex 实践都把 "what done 灬不是漂亮回答，而是可验证完成。 -p ，拳一孑 ． Done ” 0 。契约里应包含输出格式、工具使用、停止条件和验收方法。数据来溽： https://develogærs.openai.com/api/docs/guides/prompt-guidance/ ； https://openai.com/index/harness-engineering/
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-36.jpg]]
-
---
-
-### 部件二：知识必须成为 system of record
-
-页码：`page-37.jpg`
-
-部件二一个巨大的 AGENTS.md 团队原创定义知识必须成为 s stem of record 仓库 GoogIe DOCS 对 Agent 来说，不在仓库里的 Google Docs 部件二知识必须可发现知识必须可验证知识必须可维护数源： https：//openai.com/index/harness-engineering/； https://www.anthropic.com/engineering/effective-context-engineerirg-for-ai-agents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-37.jpg]]
-
---
-
-### 部件三：必须给 Agent 真正的感官和手脚
-
-页码：`page-38.jpg`
-
-团队原创定义部件三：必须给 Agent 真正的感官和手脚 0 t 亠 00 囗 UI （浏览器）指标 (Metrics & Traces) Agent 日志 (Log) 终端 (Terminal & 测试） · 0penAI 给 Codex 接了 UI 、日志、指标和 traces ； · 只有能读 UI 、看日志、跑测试，代理才有资格自证完成。 · 仅靠读代码和口头声明，很难发现真实 bugo X @？ https://www.anthropic.com/engineering/harness-design-long-running•apps
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-38.jpg]]
-
---
-
-### 部件四：必须解决长时程失忆
-
-页码：`page-39.jpg`
-
-部件 ． 四！ ；必须解决长时程失忆《部件可长时任务不能只靠大上下文硬扛。 0 0 @进葭文件 git feature 团队原创定义关键是让状态可恢复、可交接、可继续。 Anthropic 的 [ 0n9 一 running harness 用长时任务不能只靠 0 大上下文硬扛。 0-0 0 关键是让状态可恢复、可交接、可继续。数提来源： https：//www.anthropic.com/engineering/effective-harnesses-for-long-running-cgents ； https://wwwnnthropic.com/engineering/harness-design-long-nmning-apps 一 ． 一一 ． ． 一一一一一一 = 二二一
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-39.jpg]]
-
---
-
-### 部件五：验证必须外置成回路
-
-页码：`page-40.jpg`
-
-Generator 、部件五：验证必须外置成回路部件五外部 evaluator 0 负责不相信主 agento 丶夕团以原创定义 valuator 'Playwrigh@P ． 加黿怙@ 冶同式 d 数据来源 ． p § ； ／ 凹山四些国在四！些 gg / 《 ；匹， https://www.anthropic.com/engineering/demystifying-evals-for-ai-aqents
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-40.jpg]]
-
---
-
-### 部件六：边界、沙箱与熵控制必须机械化
-
-页码：`page-41.jpg`
-
-部件六：边界、沙箱与熵控制必须机械化部件八 lnput C0de & Data 0 沙箱 lint 彡风格 (Style) 风格、架构和安全不能只存在于人腌审美里。要把 taste 、 risk 和架构 governance 写进 lin••• (Architecture) 一安全 (Security) 〔 taste - risk governance Approved 团队原创定义 90 / 100 质量分 OpenAI 用 lint 回收站数来源： https://openai.com/index/harness-engineering/; https://www.anthropic.com/engineering(claud&éödé-sandboxing
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-41.jpg]]
-
---
-
-### 驾驭工程最深一层是注意力工程
-
-页码：`page-42.jpg`
-
-驾驭工程最深一层是注意力工程 0 0 0 HUMAN TIME & ATTENTION 訓亠 0 正稀缺资 ' 0 HIGH AI CAPABILITY 匡 00 驾驭工程的真正目标不是把 AI 变得更像人。低价值环节可井行妊务自动纠针刈 M 姓 0 VALUE CREATION 目标 0 0 0 一 0 OpenAl 明确说，真正稀缺趵是 human time and at 人类注意力漏斗 0 而是把人从低价值、可并行、可自动纠错环节中抽离》始意力创造性工作； ' 战略决策核心价值创造自动化过滤 & AI 辅助鼓据来源： ht:ps://openücom/index/harness engineering/
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-42.jpg]]
-
---
-
-### 人的角色发生了什么变化
-
-页码：`page-43.jpg`
-
-人的角色发生了什么变化角色变化 BEFORE: 表达者 ()x resser) " “ 0 、 〔@》乸》 。在提示词工程里， e 四 ee 疗四人主要是表达者；提示词工程。人的工作抽象层上模糊目标伊 Goal) Focus cra 厑 9 ／ 叩 u 区 specific outputs. 又@ 清新研究团队 AFTER: 设计者 & 抽象层上移。要把模糊目标翻译成 acceptance criteria; · 人的工作重点转向系统设计与评估。 = ． acceptance criteria （验收标准） Focus 虎 9 system behavior and 諂毹 e 忉 e 忉 ． 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-43.jpg]]
-
---
-
-### 驾驭工程真正要求的是组织能力，不只是模型能力
-
-页码：`page-44.jpg`
-
-驾驭工程真正要求的是组织能力，不只是模型能力组织能力真正稀缺的，不再是会不会写 prompt ，而是能不能把人类判断制度化产品（ Product) · 需求 & 定义蚴。价值发现实台理 (Governance) 0 。合规 & 风险组织能力协同引擎工程 (Engineering) 蛉。构建 & 实施。技术卓越 0 运营 (Operations) | ． · 维护 & 优化 · 持续改进 t · 标准制定。组织需要产品、工程、治理、运营协同。 · 单点高手可以做 demo ，系统化团队才能做长期稳定生产。 @ 清新研究团队 ] 2026 年 3 月 26 日
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-44.jpg]]
-
---
-
-### GIS 极客尾图
-
-页码：`page-45.png`
-
-GIS
-
-![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-45.png]]