支持增量编译wiki
This commit is contained in:
Junjian Wang
+309
-251
@@ -1,294 +1,352 @@
|
||||
---
|
||||
title: 术语表
|
||||
tags: [术语表, 核心概念]
|
||||
last_updated: 2026-04-07
|
||||
title: "术语表"
|
||||
source: "Externalization in LLM Agents: A Unified Review"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 术语表
|
||||
|
||||
本术语表汇总了 [[Harness-Engineering|Harness 工程]] 领域的核心概念，为知识库提供统一的术语枢纽。
|
||||
本术语表统一了 LLM Agent 外部化框架中的核心概念，提供中英对照和 Wikilink 链接。
|
||||
|
||||
## A
|
||||
## 核心框架
|
||||
|
||||
### Agent (智能体)
|
||||
**英文**：Agent
|
||||
**中文**：智能体
|
||||
**定义**：能够自主感知环境、做出决策并执行行动的 AI 系统。在编码场景中，智能体通常具备读取文件、执行程序、发起 HTTP 请求等工具调用能力。
|
||||
**相关概念**：[[Agent Teams|智能体团队]], [[Coding Agent|编码智能体]]
|
||||
### Externalization (外部化)
|
||||
**英文**: Externalization
|
||||
**中文**: 外部化
|
||||
**定义**: 将认知负担从模型的内部计算逐步迁移到持久、可检查和可重用的外部结构中的过程。
|
||||
**参见**: [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
|
||||
### Agent Teams (智能体团队)
|
||||
**英文**：Agent Teams
|
||||
**中文**：智能体团队
|
||||
**定义**：多个智能体通过角色分工、协作协议和差异化行为共同完成复杂任务的系统。需要模型原生支持角色锚定、对抗性推理和协议遵守。
|
||||
**相关概念**：[[MiniMax M2.7]], [[Multi-Agent Collaboration|多智能体协作]]
|
||||
|
||||
### Anthropic Harness Design (Anthropic Harness 设计)
|
||||
**英文**：Anthropic Harness Design
|
||||
**中文**：Anthropic Harness 设计
|
||||
**定义**：Anthropic 团队提出的多智能体架构，包含 Planner（规划者）、Generator（生成者）和 Evaluator（评估者）三种角色，通过生成-评估循环提升输出质量。
|
||||
**相关概念**：[[Generator-Evaluator Loop|生成-评估循环]], [[Context Reset|上下文重置]]
|
||||
|
||||
## B
|
||||
|
||||
### Build-Verify Loop (构建-验证循环)
|
||||
**英文**：Build-Verify Loop
|
||||
**中文**：构建-验证循环
|
||||
**定义**：智能体在完成任务过程中自主进行的迭代改进流程，包括规划发现、构建实现、验证测试和修复问题四个阶段。
|
||||
**相关概念**：[[Self-Verification|自我验证]], [[Reasoning Sandwich|推理三明治]]
|
||||
|
||||
## C
|
||||
|
||||
### Codex (Codex 模型)
|
||||
**英文**：Codex
|
||||
**中文**：Codex 模型
|
||||
**定义**：OpenAI 推出的专门用于代码生成的模型系列，在 Harness 工程中被用于从零生成完整产品代码库。
|
||||
**相关概念**：[[OpenAI Harness Engineering|OpenAI Harness 工程]]
|
||||
|
||||
### Coding Agent (编码智能体)
|
||||
**英文**：Coding Agent
|
||||
**中文**：编码智能体
|
||||
**定义**：专门用于软件工程任务的 AI 智能体，能够理解代码库、编写代码、运行测试和调试问题。
|
||||
**相关概念**：[[Harness|Harness]], [[Agent|智能体]]
|
||||
|
||||
### Context Engineering (上下文工程)
|
||||
**英文**：Context Engineering
|
||||
**中文**：上下文工程
|
||||
**定义**：Harness 工程的三大支柱之一，专注于确保智能体在正确的时间获得正确的信息，包括静态上下文和动态上下文。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]], [[Context Reset|上下文重置]]
|
||||
|
||||
### Context Reset (上下文重置)
|
||||
**英文**：Context Reset
|
||||
**中文**：上下文重置
|
||||
**定义**：一种解决长任务中上下文窗口填充和"上下文焦虑"问题的技术，通过清空上下文窗口并使用结构化交接传递状态来实现。
|
||||
**相关概念**：[[Context Compaction|上下文压缩]], [[Context Anxiety|上下文焦虑]]
|
||||
|
||||
### Context Anxiety (上下文焦虑)
|
||||
**英文**：Context Anxiety
|
||||
**中文**：上下文焦虑
|
||||
**定义**：模型在接近其认为的上下文限制时提前结束工作的倾向，Claude Sonnet 4.5 表现出较强的这种行为。
|
||||
**相关概念**：[[Context Reset|上下文重置]], [[Context Window|上下文窗口]]
|
||||
|
||||
### Context Compaction (上下文压缩)
|
||||
**英文**：Context Compaction
|
||||
**中文**：上下文压缩
|
||||
**定义**：通过摘要方式保留对话连续性的技术，但无法为智能体提供干净的状态，上下文焦虑问题仍可能存在。
|
||||
**相关概念**：[[Context Reset|上下文重置]]
|
||||
|
||||
## D
|
||||
|
||||
### Doom Loop (末日循环)
|
||||
**英文**：Doom Loop
|
||||
**中文**：末日循环
|
||||
**定义**：智能体在陷入困境时对同一错误方法进行小幅变异的重复尝试现象，可能多达 10 次以上。
|
||||
**相关概念**：[[Loop Detection|循环检测]]
|
||||
|
||||
## E
|
||||
|
||||
### Entropy Management (熵管理)
|
||||
**英文**：Entropy Management
|
||||
**中文**：熵管理
|
||||
**定义**：Harness 工程的三大支柱之一，通过定期清理智能体来管理 AI 生成代码库中随时间积累的熵（文档漂移、命名约定分歧、死代码堆积等）。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]], [[Garbage Collection|垃圾回收]]
|
||||
|
||||
### Evaluator (评估者)
|
||||
**英文**：Evaluator
|
||||
**中文**：评估者
|
||||
**定义**：Anthropic Harness 设计中的三种角色之一，负责评估 Generator 的输出质量，提供具体的反馈和评分。
|
||||
**相关概念**：[[Generator|生成者]], [[Planner|规划者]]
|
||||
|
||||
## F
|
||||
|
||||
### Feedforward (前馈控制)
|
||||
**英文**：Feedforward
|
||||
**中文**：前馈控制
|
||||
**定义**：预期智能体行为并在其行动前进行引导的控制方式，提高智能体第一次尝试就产生良好结果的概率。
|
||||
**相关概念**：[[Feedback|反馈控制]], [[Guide|引导]]
|
||||
|
||||
### Feedback (反馈控制)
|
||||
**英文**：Feedback
|
||||
**中文**：反馈控制
|
||||
**定义**：在智能体行动后进行观察并帮助其自我纠正的控制方式，特别是当产生针对 LLM 消费优化的信号时效果显著。
|
||||
**相关概念**：[[Feedforward|前馈控制]], [[Sensor|传感器]]
|
||||
|
||||
## G
|
||||
|
||||
### Garbage Collection (垃圾回收)
|
||||
**英文**：Garbage Collection
|
||||
**中文**：垃圾回收
|
||||
**定义**：OpenAI 团队采用的定期清理流程，通过"黄金原则"和后台 Codex 任务来扫描偏差、更新质量等级并发起针对性重构。
|
||||
**相关概念**：[[Entropy Management|熵管理]]
|
||||
|
||||
### Generator (生成者)
|
||||
**英文**：Generator
|
||||
**中文**：生成者
|
||||
**定义**：Anthropic Harness 设计中的三种角色之一，负责实际创建输出（如前端代码、应用功能等）。
|
||||
**相关概念**：[[Evaluator|评估者]], [[Planner|规划者]]
|
||||
|
||||
### Generator-Evaluator Loop (生成-评估循环)
|
||||
**英文**：Generator-Evaluator Loop
|
||||
**中文**：生成-评估循环
|
||||
**定义**：受 GAN 启发的多智能体结构，Generator 生成输出，Evaluator 评估并提供反馈，Generator 根据反馈进行迭代改进。
|
||||
**相关概念**：[[Anthropic-Harness-Design|Anthropic Harness 设计]]
|
||||
|
||||
### Glossary (术语表)
|
||||
**英文**：Glossary
|
||||
**中文**：术语表
|
||||
**定义**：WikiLLM 知识库的核心枢纽文档，统一术语翻译、提供中英对照，并通过 wikilinks 连接所有相关概念。
|
||||
**相关概念**：[[Wikilink|Wikilink]], [[WikiLLM]]
|
||||
|
||||
## H
|
||||
### Cognitive Artifact (认知人工制品)
|
||||
**英文**: Cognitive Artifact
|
||||
**中文**: 认知人工制品
|
||||
**定义**: 设计用于维持、显示或操作信息的人工设备，通过改变任务本身的结构来改变认知性能。
|
||||
**参见**: [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
|
||||
### Harness (Harness)
|
||||
**英文**：Harness
|
||||
**中文**：Harness
|
||||
**定义**：AI 智能体之外的一切，包括系统提示、工具选择、执行流程、约束条件、反馈循环等。公式：Agent = Model + Harness。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]], [[Agent|智能体]]
|
||||
**英文**: Harness
|
||||
**中文**: Harness
|
||||
**定义**: 将原始模型能力转化为可靠 Agent 行为的脚手架，是承载记忆、技能、协议并提供编排逻辑、约束、可观测性和反馈循环的工程层。
|
||||
**参见**: [[Harness-Engineering|Harness 工程]]
|
||||
|
||||
### Harness Engineering (Harness 工程)
|
||||
**英文**：Harness Engineering
|
||||
**中文**：Harness 工程
|
||||
**定义**：设计和实现使 AI 智能体可靠工作的系统的新学科，包括约束智能体行为、告知智能体应该做什么、验证智能体正确执行、纠正智能体错误四个方面。
|
||||
**相关概念**：[[Context-Engineering|上下文工程]], [[Architectural-Constraints|架构约束]], [[Entropy Management|熵管理]]
|
||||
### Representational Transformation (表征转换)
|
||||
**英文**: Representational Transformation
|
||||
**中文**: 表征转换
|
||||
**定义**: 认知人工制品的核心作用——重组问题，使智能体能够用它已经拥有的能力更可靠地解决问题。
|
||||
|
||||
### Harness Template (Harness 模板)
|
||||
**英文**：Harness Template
|
||||
**中文**：Harness 模板
|
||||
**定义**：为常见服务拓扑（如数据仪表板、CRUD 业务服务、事件处理器）准备的引导和传感器捆绑包，可实例化用于特定项目。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]]
|
||||
## 记忆系统
|
||||
|
||||
## L
|
||||
### Memory System (记忆系统)
|
||||
**英文**: Memory System
|
||||
**中文**: 记忆系统
|
||||
**定义**: 外部化 Agent 状态跨时间的系统，允许积累的知识在单个会话之外持续存在，并在相关时被选择性检索。
|
||||
**参见**: [[Memory-Systems|记忆系统]]
|
||||
|
||||
### LangChain Harness Engineering (LangChain Harness 工程)
|
||||
**英文**：LangChain Harness Engineering
|
||||
**中文**：LangChain Harness 工程
|
||||
**定义**：LangChain 团队通过仅改变 Harness 将编码智能体在 Terminal Bench 2.0 上的表现从 52.8% 提升到 66.5%（Top 30 到 Top 5）的实践。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]], [[Self-Verification|自我验证]]
|
||||
### Working Context (工作上下文)
|
||||
**英文**: Working Context
|
||||
**中文**: 工作上下文
|
||||
**定义**: 当前任务的实时中间状态：打开的文件、临时变量、活跃假设、部分计划和执行检查点。
|
||||
|
||||
### Layered Domain Architecture (分层领域架构)
|
||||
**英文**：Layered Domain Architecture
|
||||
**中文**：分层领域架构
|
||||
**定义**：OpenAI 采用的严格架构模型，每个业务领域划分为固定的层组（Types → Config → Repo → Service → Runtime → UI），依赖方向经过严格验证。
|
||||
**相关概念**：[[Architectural-Constraints|架构约束]]
|
||||
### Episodic Experience (情景经验)
|
||||
**英文**: Episodic Experience
|
||||
**中文**: 情景经验
|
||||
**定义**: 记录先前运行中发生的事情：决策点、工具调用、失败、结果和反思。
|
||||
|
||||
### Loop Detection (循环检测)
|
||||
**英文**：Loop Detection
|
||||
**中文**：循环检测
|
||||
**定义**：LangChain 采用的中间件，通过钩子跟踪每个文件的编辑次数，在对同一文件进行 N 次编辑后添加"考虑重新考虑你的方法"的上下文。
|
||||
**相关概念**：[[Doom Loop|末日循环]], [[Middleware|中间件]]
|
||||
### Semantic Knowledge (语义知识)
|
||||
**英文**: Semantic Knowledge
|
||||
**中文**: 语义知识
|
||||
**定义**: 存储在任何单个情节之外都存在的抽象：领域事实、一般启发式、项目约定和稳定的世界知识。
|
||||
|
||||
## M
|
||||
### Personalized Memory (个性化记忆)
|
||||
**英文**: Personalized Memory
|
||||
**中文**: 个性化记忆
|
||||
**定义**: 跟踪关于特定用户、团队或环境的稳定信息：偏好、习惯、重复出现的约束和先前的交互。
|
||||
|
||||
### Middleware (中间件)
|
||||
**英文**：Middleware
|
||||
**中文**：中间件
|
||||
**定义**：LangChain 结构化 Harness 的方式，通过可组合的中间件层在不修改核心智能体逻辑的情况下添加特定功能。
|
||||
**相关概念**：[[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
## 技能系统
|
||||
|
||||
### MiniMax M2.7 (MiniMax M2.7 模型)
|
||||
**英文**：MiniMax M2.7
|
||||
**中文**：MiniMax M2.7 模型
|
||||
**定义**：MiniMax 推出的深度参与自我进化的模型，能够构建复杂智能体 Harness、完成高度复杂的生产力任务，包括 Agent Teams、复杂 Skills 和动态工具搜索。
|
||||
**相关概念**：[[Agent Teams|智能体团队]], [[Self-Evolution|自我进化]]
|
||||
### Skill System (技能系统)
|
||||
**英文**: Skill System
|
||||
**中文**: 技能系统
|
||||
**定义**: 将程序、最佳实践和操作指导打包成可重用的人工制品的系统，而不是依赖模型的权重在每次调用时重新生成特定任务的知识。
|
||||
**参见**: [[Skill-Systems|技能系统]]
|
||||
|
||||
### Mitchellh AI Adoption Journey (Mitchellh AI 采用之旅)
|
||||
**英文**：Mitchellh AI Adoption Journey
|
||||
**中文**：Mitchellh AI 采用之旅
|
||||
**定义**：HashiCorp 创始人 Mitchell Hashimoto 分享的个人 AI 工具采用历程，包括从聊天机器人到始终运行智能体的六个阶段。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]]
|
||||
### Operational Procedure (操作程序)
|
||||
**英文**: Operational Procedure
|
||||
**中文**: 操作程序
|
||||
**定义**: 任务骨架：将复杂工作分解为步骤、阶段、依赖关系和停止条件。
|
||||
|
||||
## N
|
||||
### Decision Heuristic (决策启发式)
|
||||
**英文**: Decision Heuristic
|
||||
**中文**: 决策启发式
|
||||
**定义**: 在分支处管理发生情况的实用经验法则，从经验中得出而不是仅靠穷举搜索。
|
||||
|
||||
### NxCode Harness Engineering (NxCode Harness 工程)
|
||||
**英文**：NxCode Harness Engineering
|
||||
**中文**：NxCode Harness 工程
|
||||
**定义**：NxCode 团队提供的 Harness 工程完整指南，总结了三大支柱、实践框架和常见错误。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]]
|
||||
### Normative Constraint (规范性约束)
|
||||
**英文**: Normative Constraint
|
||||
**中文**: 规范性约束
|
||||
**定义**: 程序被视为可接受的条件，包括测试要求、范围限制、访问限制、可追溯性期望和特定领域操作规则。
|
||||
|
||||
## O
|
||||
### Progressive Disclosure (渐进式披露)
|
||||
**英文**: Progressive Disclosure
|
||||
**中文**: 渐进式披露
|
||||
**定义**: 一种分层加载策略，首先暴露技能的存在，仅在需要时才加载更深的细节。
|
||||
|
||||
### OpenAI Harness Engineering (OpenAI Harness 工程)
|
||||
**英文**：OpenAI Harness Engineering
|
||||
**中文**：OpenAI Harness 工程
|
||||
**定义**：OpenAI 团队在 5 个月内构建了超过 100 万行代码的产品，其中零行代码由人工编写，证明了 Harness 工程在生产规模上的有效性。
|
||||
**相关概念**：[[Harness-Engineering|Harness 工程]], [[Codex|Codex 模型]]
|
||||
## 协议系统
|
||||
|
||||
### Observability Stack (可观测性堆栈)
|
||||
**英文**：Observability Stack
|
||||
**中文**：可观测性堆栈
|
||||
**定义**：OpenAI 为 Codex 提供的日志、指标和追踪记录展示系统，使智能体能够直接访问应用程序的运行状态。
|
||||
**相关概念**：[[Context-Engineering|上下文工程]]
|
||||
### Agent Protocol (智能体协议)
|
||||
**英文**: Agent Protocol
|
||||
**中文**: 智能体协议
|
||||
**定义**: 定义了用于发现、调用、委托和权限管理的显式机器可读契约，而不是依赖临时提示级别的协调。
|
||||
**参见**: [[Agent-Protocols|智能体协议]]
|
||||
|
||||
## P
|
||||
### Invocation Grammar (调用语法)
|
||||
**英文**: Invocation Grammar
|
||||
**中文**: 调用语法
|
||||
**定义**: 每个工具调用、API 请求或委托消息都需要的格式：参数名称、类型、排序和返回结构。
|
||||
|
||||
### Planner (规划者)
|
||||
**英文**：Planner
|
||||
**中文**：规划者
|
||||
**定义**：Anthropic Harness 设计中的三种角色之一，负责将简单的 1-4 句话提示扩展为完整的产品规格。
|
||||
**相关概念**：[[Generator|生成者]], [[Evaluator|评估者]]
|
||||
### Lifecycle Semantics (生命周期语义)
|
||||
**英文**: Lifecycle Semantics
|
||||
**中文**: 生命周期语义
|
||||
**定义**: 多步交互需要的协调规则：谁接下来行动，允许什么状态转换，任务何时完成或失败。
|
||||
|
||||
## R
|
||||
### MCP (Model Context Protocol)
|
||||
**英文**: Model Context Protocol (MCP)
|
||||
**中文**: 模型上下文协议 (MCP)
|
||||
**定义**: Anthropic 提出的标准化协议，为智能体提供跨异构服务发现工具、检查其模式和调用它们的方式。
|
||||
|
||||
### Reasoning Sandwich (推理三明治)
|
||||
**英文**：Reasoning Sandwich
|
||||
**中文**：推理三明治
|
||||
**定义**：LangChain 采用的推理预算分配策略，在规划和验证阶段使用高推理预算，在实现阶段使用中等推理预算。
|
||||
**相关概念**：[[Build-Verify Loop|构建-验证循环]]
|
||||
### A2A (Agent-to-Agent Protocol)
|
||||
**英文**: Agent-to-Agent Protocol (A2A)
|
||||
**中文**: 智能体到智能体协议 (A2A)
|
||||
**定义**: Google 提出的标准化智能体间通信协议，支持能力发现、任务委托和状态交换。
|
||||
|
||||
### Ralph Wiggum Loop (Ralph Wiggum 循环)
|
||||
**英文**：Ralph Wiggum Loop
|
||||
**中文**：Ralph Wiggum 循环
|
||||
**定义**：使用钩子在智能体退出时强制其继续执行的循环模式，用于验证环节。
|
||||
**相关概念**：[[Self-Verification|自我验证]]
|
||||
## Harness 工程
|
||||
|
||||
## S
|
||||
### Agent Loop (智能体循环)
|
||||
**英文**: Agent Loop
|
||||
**中文**: 智能体循环
|
||||
**定义**: Harness 的时间骨干，实现感知-检索-计划-行动-观察周期。
|
||||
**参见**: [[Harness-Engineering|Harness 工程]]
|
||||
|
||||
### Self-Verification (自我验证)
|
||||
**英文**：Self-Verification
|
||||
**中文**：自我验证
|
||||
**定义**：智能体通过运行测试、阅读完整输出并与原始要求进行比较来自我改进的能力。
|
||||
**相关概念**：[[Build-Verify Loop|构建-验证循环]]
|
||||
### Sandboxing (沙箱)
|
||||
**英文**: Sandboxing
|
||||
**中文**: 沙箱
|
||||
**定义**: 创建受控的执行边界，限制 Agent 可以读取、写入和修改的内容，并提供使失败可诊断和回滚可行的可再现性保证。
|
||||
|
||||
### Self-Evolution (自我进化)
|
||||
**英文**：Self-Evolution
|
||||
**中文**：自我进化
|
||||
**定义**：模型深度参与自身进化的过程，包括更新自身记忆、构建复杂技能、根据实验结果改进学习过程和 Harness。
|
||||
**相关概念**：[[MiniMax M2.7|MiniMax M2.7 模型]]
|
||||
### Observability (可观测性)
|
||||
**英文**: Observability
|
||||
**中文**: 可观测性
|
||||
**定义**: 使 Agent 的内部轨迹对开发者、操作员和 Agent 本身可见的机制，包括结构化日志、执行轨迹和聚合指标。
|
||||
|
||||
### Sensor (传感器)
|
||||
**英文**：Sensor
|
||||
**中文**：传感器
|
||||
**定义**：观察智能体行动后结果并帮助其自我纠正的反馈控制，包括计算型和推理型两种类型。
|
||||
**相关概念**：[[Feedback|反馈控制]]
|
||||
### Context Budget Management (上下文预算管理)
|
||||
**英文**: Context Budget Management
|
||||
**中文**: 上下文预算管理
|
||||
**定义**: 主动管理最稀缺的共享资源——上下文窗口——的策略，包括摘要、基于优先级的驱逐和分阶段加载。
|
||||
|
||||
## 历史演进
|
||||
|
||||
### Weights Layer (权重层)
|
||||
**英文**: Weights Layer
|
||||
**中文**: 权重层
|
||||
**定义**: LLM 部署的最早浪潮，其中能力几乎完全与模型参数等同。
|
||||
**参见**: [[From-Weights-to-Context-to-Harness|从权重到上下文到 Harness]]
|
||||
|
||||
### Context Layer (上下文层)
|
||||
**英文**: Context Layer
|
||||
**中文**: 上下文层
|
||||
**定义**: 注意力从模型修改转向输入设计的阶段，包括提示工程、思维链、ReAct、RAG 等技术。
|
||||
|
||||
### Harness Layer (Harness 层)
|
||||
**英文**: Harness Layer
|
||||
**中文**: Harness 层
|
||||
**定义**: 当前阶段，其中能力延伸超出提示管理进入持久基础设施。
|
||||
|
||||
## 理论基础
|
||||
|
||||
### Distributed Cognition (分布式认知)
|
||||
**英文**: Distributed Cognition
|
||||
**中文**: 分布式认知
|
||||
**定义**: 拒绝认知完全驻留在个人心灵内的观点，而是将认知过程定位在人、人工制品、表征和协调实践之间。
|
||||
|
||||
### Complementary Strategies (互补策略)
|
||||
**英文**: Complementary Strategies
|
||||
**中文**: 互补策略
|
||||
**定义**: Kirsh 的理论，认为智能体不仅通过在内部更努力地思考来提高性能，还通过重组外部环境使一些认知工作卸载到其中来提高性能。
|
||||
|
||||
## 实践术语
|
||||
|
||||
### Context Anxiety (上下文焦虑)
|
||||
**英文**: Context Anxiety
|
||||
**中文**: 上下文焦虑
|
||||
**定义**: 一些模型表现出的倾向，当它们接近认为的上下文限制时，会过早地结束工作。
|
||||
|
||||
### Context Reset (上下文重置)
|
||||
**英文**: Context Reset
|
||||
**中文**: 上下文重置
|
||||
**定义**: 完全清除上下文窗口并启动一个新的 Agent，结合结构化移交来携带前一个 Agent 的状态和下一步。
|
||||
|
||||
### Sprint Contract (冲刺契约)
|
||||
**英文**：Sprint Contract
|
||||
**中文**：冲刺契约
|
||||
**定义**：在每个冲刺前，Generator 和 Evaluator 协商达成的协议，定义该阶段工作的"完成"标准。
|
||||
**相关概念**：[[Anthropic-Harness-Design|Anthropic Harness 设计]]
|
||||
**英文**: Sprint Contract
|
||||
**中文**: 冲刺契约
|
||||
**定义**: 在每个冲刺之前，生成器和评估器协商的协议，就在编写任何代码之前该工作块的"完成"是什么样子达成一致。
|
||||
|
||||
## T
|
||||
### Planner-Generator-Evaluator (规划器-生成器-评估器)
|
||||
**英文**: Planner-Generator-Evaluator
|
||||
**中文**: 规划器-生成器-评估器
|
||||
**定义**: 一种三 Agent 架构，用于长运行自主编码：规划器将简单提示扩展为完整规范，生成器一次实现一个功能，评估器测试并评分结果。
|
||||
**参见**: [[Long-Running-Harness-Design|长运行应用的 Harness 设计]]
|
||||
|
||||
### Terminal Bench (终端基准测试)
|
||||
**英文**：Terminal Bench
|
||||
**中文**：终端基准测试
|
||||
**定义**：评估智能体编码能力的标准基准测试，包含机器学习、调试、生物学等多个领域的任务。
|
||||
**相关概念**：[[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
### Agent-First World (智能体优先的世界)
|
||||
**英文**: Agent-First World
|
||||
**中文**: 智能体优先的世界
|
||||
**定义**: 一种软件工程范式，其中没有一行代码是人工编写的，人类工程师的工作重点转向设计环境、明确意图和构建反馈回路。
|
||||
**参见**: [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
|
||||
## W
|
||||
### Progressive Disclosure (渐进式披露)
|
||||
**英文**: Progressive Disclosure
|
||||
**中文**: 渐进式披露
|
||||
**定义**: 一种情境管理策略，智能体从一个小而稳定的切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。
|
||||
**参见**: [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
|
||||
### Wikilink (Wikilink)
|
||||
**英文**：Wikilink
|
||||
**中文**：Wikilink
|
||||
**定义**：使用 `[[文档标题]]` 格式的内部链接，在 Obsidian 等工具中支持双向链接和图谱视图。
|
||||
**相关概念**：[[Backlink|反向链接]], [[Glossary|术语表]]
|
||||
### Doc-Gardening (文档园艺)
|
||||
**英文**: Doc-Gardening
|
||||
**中文**: 文档园艺
|
||||
**定义**: 定期运行的智能体，扫描那些不再反映真实代码行为的过时或废弃文档，并发起修复用的 Pull Request。
|
||||
|
||||
### WikiLLM (WikiLLM)
|
||||
**英文**：WikiLLM
|
||||
**中文**：WikiLLM
|
||||
**定义**：本项目的名称，一个利用 LLM 构建个人知识库的系统，通过"编译"原始数据生成结构化、交叉链接的高质量中文 Wiki。
|
||||
**相关概念**：[[Glossary|术语表]], [[INDEX]]
|
||||
### Golden Principles (黄金原则)
|
||||
**英文**: Golden Principles
|
||||
**中文**: 黄金原则
|
||||
**定义**: 带有主观意见的机械规则，旨在保持代码库的可读性和一致性，以便将来运行智能体。
|
||||
|
||||
---
|
||||
### AI Slop (AI 残渣)
|
||||
**英文**: AI Slop
|
||||
**中文**: AI 残渣
|
||||
**定义**: 智能体复现代码仓库中已存在的不均衡或不够理想的模式，随着时间的推移导致的漂移。
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 自动生成*
|
||||
### Meta-Harness (元 Harness)
|
||||
**英文**: Meta-Harness
|
||||
**中文**: 元 Harness
|
||||
**定义**: 一个外环系统，用于搜索和优化 LLM 应用的 Harness 代码，使用编码智能体通过文件系统访问完整历史记录（源代码、执行轨迹、分数）来提议和评估新的 Harness。
|
||||
**参见**: [[Meta-Harness|Meta-Harness：模型 Harness 的端到端优化]]
|
||||
|
||||
### Code-Space Search (代码空间搜索)
|
||||
**英文**: Code-Space Search
|
||||
**中文**: 代码空间搜索
|
||||
**定义**: Meta-Harness 的关键设计选择，将 Harness 优化发生在代码空间中，通过检查执行轨迹推断为什么失败以及哪些早期设计选择导致了失败，而不仅仅是失败本身。
|
||||
|
||||
### Computational vs Inferential (计算型 vs 推理型)
|
||||
**英文**: Computational vs Inferential
|
||||
**中文**: 计算型 vs 推理型
|
||||
**定义**: Harness 中指南和传感器的两种执行类型：计算型是确定性且快速的（测试、lint、类型检查）；推理型是语义分析、AI 代码审查、"LLM 作为法官"。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Feedforward Guide (前馈指南)
|
||||
**英文**: Feedforward Guide
|
||||
**中文**: 前馈指南
|
||||
**定义**: 在智能体行动之前提供的指导，包括原则、规则、参考文档、操作指南等，增加智能体第一次就做对的概率。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Feedback Sensor (反馈传感器)
|
||||
**英文**: Feedback Sensor
|
||||
**中文**: 反馈传感器
|
||||
**定义**: 在智能体行动之后提供的验证机制，包括静态分析、日志、浏览器测试、代码审查智能体等，用于自我纠正问题。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Harness Template (Harness 模板)
|
||||
**英文**: Harness Template
|
||||
**中文**: Harness 模板
|
||||
**定义**: 针对常见应用拓扑（数据仪表板、CRUD 业务服务、事件处理器）的指南和传感器捆绑包，可以作为团队的起点。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Maintainability Harness (可维护性 Harness)
|
||||
**英文**: Maintainability Harness
|
||||
**中文**: 可维护性 Harness
|
||||
**定义**: 监管内部代码质量和可维护性的 Harness 类别，包括 lint、结构测试、代码覆盖等工具。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Architecture Fitness Harness (架构适用性 Harness)
|
||||
**英文**: Architecture Fitness Harness
|
||||
**中文**: 架构适用性 Harness
|
||||
**定义**: 定义和检查应用程序架构特征的指南和传感器，类似于架构适用性函数。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Behaviour Harness (行为 Harness)
|
||||
**英文**: Behaviour Harness
|
||||
**中文**: 行为 Harness
|
||||
**定义**: 引导和感知应用程序是否按需要功能运行的 Harness 类别，包括功能规范和测试套件。
|
||||
**参见**: [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
|
||||
### Rippable Harness (可剥离 Harness)
|
||||
**英文**: Rippable Harness
|
||||
**中文**: 可剥离 Harness
|
||||
**定义**: 设计为可以移除"智能"逻辑的 Harness，当模型变得足够智能不需要时。
|
||||
**参见**: [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]]
|
||||
|
||||
### Three Pillars of Harness Engineering (Harness 工程三大支柱)
|
||||
**英文**: Three Pillars of Harness Engineering
|
||||
**中文**: Harness 工程三大支柱
|
||||
**定义**: OpenAI 框架组织的三个核心类别：上下文工程、架构约束、熵管理（垃圾收集）。
|
||||
**参见**: [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]]
|
||||
|
||||
### Context Engineering (上下文工程)
|
||||
**英文**: Context Engineering
|
||||
**中文**: 上下文工程
|
||||
**定义**: 确保智能体在正确时间拥有正确信息的学科，包括存储库本地文档和动态可观测性数据。
|
||||
**参见**: [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]]
|
||||
|
||||
### Architectural Constraints (架构约束)
|
||||
**英文**: Architectural Constraints
|
||||
**中文**: 架构约束
|
||||
**定义**: 机械地强制执行好代码样子的机制，包括依赖分层规则、确定性 linter、结构测试等。
|
||||
**参见**: [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]]
|
||||
|
||||
### Entropy Management (熵管理)
|
||||
**英文**: Entropy Management
|
||||
**中文**: 熵管理
|
||||
**定义**: 定期清理智能体，用于解决 AI 生成代码库随时间积累的熵（文档漂移、命名约定发散、死代码积累）。
|
||||
**参见**: [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]]
|
||||
|
||||
### Reasoning Sandwich (推理三明治)
|
||||
**英文**: Reasoning Sandwich
|
||||
**中文**: 推理三明治
|
||||
**定义**: 一种推理预算分配策略：规划使用高推理、实现使用中推理、验证使用高推理。
|
||||
**参见**: [[LangChain-Harness-Engineering|LangChain Harness 工程实践]]
|
||||
|
||||
### Self-Verification Loop (自我验证循环)
|
||||
**英文**: Self-Verification Loop
|
||||
**中文**: 自我验证循环
|
||||
**定义**: 让智能体验证其工作的机制：规划与发现、构建、验证、修复。
|
||||
**参见**: [[LangChain-Harness-Engineering|LangChain Harness 工程实践]]
|
||||
|
||||
### Managed Agents (托管智能体)
|
||||
**英文**: Managed Agents
|
||||
**中文**: 托管智能体
|
||||
**定义**: Anthropic 的托管服务，通过一组通用接口虚拟化智能体组件（会话、Harness、沙箱）来运行长 horizon 智能体。
|
||||
**参见**: [[Managed-Agents-Decoupling-Brain-from-Hands|Managed Agents：将大脑与手分离]]
|
||||
|
||||
### Session (会话)
|
||||
**英文**: Session
|
||||
**中文**: 会话
|
||||
**定义**: Managed Agents 中发生的一切的仅追加日志，作为生活在 Claude 上下文窗口之外的上下文对象。
|
||||
**参见**: [[Managed-Agents-Decoupling-Brain-from-Hands|Managed Agents：将大脑与手分离]]
|
||||
|
||||
### Meta-Harness (元 Harness)
|
||||
**英文**: Meta-Harness
|
||||
**中文**: 元 Harness
|
||||
**定义**: 一种系统，具有允许许多不同 Harness 的通用接口，而对 Claude 未来将需要的特定 Harness 没有意见。
|
||||
**参见**: [[Managed-Agents-Decoupling-Brain-from-Hands|Managed Agents：将大脑与手分离]]
|
||||
|
||||
### Model Self-Evolution (模型自我进化)
|
||||
**英文**: Model Self-Evolution
|
||||
**中文**: 模型自我进化
|
||||
**定义**: 模型深度参与迭代自己的过程，包括构建强化学习 Harness、更新记忆、驱动自身的强化学习。
|
||||
**参见**: [[MiniMax-M27-Self-Evolution|MiniMax M2.7：开启模型的自我进化]]
|
||||
|
||||
### Agent Teams (智能体团队)
|
||||
**英文**: Agent Teams
|
||||
**中文**: 智能体团队
|
||||
**定义**: 多智能体协作的原生能力，要求角色边界、对抗性推理、协议遵循、行为分化内化到模型中。
|
||||
**参见**: [[MiniMax-M27-Self-Evolution|MiniMax M2.7：开启模型的自我进化]]
|
||||
|
||||
### Six Stages of AI Adoption (AI 采用的六个阶段)
|
||||
**英文**: Six Stages of AI Adoption
|
||||
**中文**: AI 采用的六个阶段
|
||||
**定义**: Mitchell Hashimoto 的采用路径：放弃聊天机器人界面、重现自己的工作、日终智能体、外包确定的任务、工程化 Harness、始终有一个智能体在运行。
|
||||
**参见**: [[Mitchellh-AI-Adoption-Journey|Mitchell Hashimoto 的 AI 采用之旅]]
|
||||
|
||||
+52
-64
@@ -1,84 +1,72 @@
|
||||
---
|
||||
title: WikiLLM 知识库首页
|
||||
tags: [首页, 索引, 导航]
|
||||
last_updated: 2026-04-07
|
||||
title: "WikiLLM 知识库索引"
|
||||
source: "Externalization in LLM Agents: A Unified Review"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# WikiLLM 知识库
|
||||
# WikiLLM 知识库索引
|
||||
|
||||
欢迎来到 **WikiLLM**——一个关于 [[Harness-Engineering|Harness 工程]] 的中文知识库。本 wiki 基于多篇权威来源编译而成，旨在为 AI 智能体时代的软件工程提供系统化的指南。
|
||||
欢迎来到 WikiLLM 知识库！本 wiki 基于论文《Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering》编译而成。
|
||||
|
||||
> **Harness 工程**是设计和实现使 AI 智能体可靠工作的系统的新学科。如果说 2025 年是 AI 智能体验证它们能够编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。
|
||||
## 快速导航
|
||||
|
||||
---
|
||||
- [[Glossary|术语表]] - 核心概念定义与对照
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]] - 核心理论框架
|
||||
- [[Harness-Engineering|Harness 工程]] - 统一集成层
|
||||
|
||||
## 📚 核心概念
|
||||
## 核心概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]] - Harness 工程的完整概述，包括三大支柱、为什么现在重要、以及实践中的方法
|
||||
- [[Context-Engineering|上下文工程]] - 如何确保智能体在正确的时间获得正确的信息
|
||||
- [[Architectural-Constraints|架构约束]] - 如何机械地强制执行好代码的样子，而不是仅仅告诉智能体"写好代码"
|
||||
- [[Anthropic-Harness-Design|Anthropic Harness 设计]] - Anthropic 的三智能体架构：Planner、Generator、Evaluator
|
||||
- [[Self-Verification|自我验证]] - 让智能体通过构建-验证循环自我改进的技术
|
||||
本知识库围绕 LLM Agent 的**外部化框架**组织，涵盖四大支柱：
|
||||
|
||||
---
|
||||
### 1. 外部化理论
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]] - 外部化作为组织原则
|
||||
- [[From-Weights-to-Context-to-Harness|从权重到上下文到 Harness]] - 历史演进路径
|
||||
|
||||
## 🛠️ 实践指南
|
||||
### 2. 三大外部化维度
|
||||
- [[Memory-Systems|记忆系统]] - 跨时间外部化状态
|
||||
- [[Skill-Systems|技能系统]] - 外部化程序专长
|
||||
- [[Agent-Protocols|智能体协议]] - 外部化交互结构
|
||||
|
||||
- [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] - HashiCorp 创始人从怀疑论者到深度用户的六个阶段
|
||||
- [[Building-Your-First-Harness|构建你的第一个 Harness]] - 从个人开发者到工程组织的三级实用框架
|
||||
### 3. Harness 工程
|
||||
- [[Harness-Engineering|Harness 工程]] - 统一协调层
|
||||
- [[Harness-Engineering-Complete-Guide|Harness 工程完整指南]] - NxCode 的完整 Harness 工程指南
|
||||
- [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]] - Martin Fowler 的指南与传感器框架
|
||||
- [[Harness-Engineering-First-Thoughts|Harness 工程：最初的思考]] - Martin Fowler 团队的早期备忘录
|
||||
- [[Meta-Harness|Meta-Harness：模型 Harness 的端到端优化]] - 斯坦福/MIT 的自动 Harness 优化研究
|
||||
|
||||
---
|
||||
### 4. 实践指南
|
||||
- [[Long-Running-Harness-Design|长运行应用的 Harness 设计]] - Anthropic 团队的多 Agent 架构实践
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]] - 完全由智能体生成代码的产品开发实践
|
||||
- [[Mitchellh-AI-Adoption-Journey|Mitchell Hashimoto 的 AI 采用之旅]] - HashiCorp 创始人从怀疑论者到深度用户的六个阶段
|
||||
- [[LangChain-Harness-Engineering|LangChain Harness 工程实践]] - 从 Top 30 到 Top 5 的 Harness 优化经验
|
||||
- [[Managed-Agents-Decoupling-Brain-from-Hands|Managed Agents：将大脑与手分离]] - Anthropic 的托管智能体架构设计
|
||||
- [[MiniMax-M27-Self-Evolution|MiniMax M2.7：开启模型的自我进化]] - 模型参与迭代自己的实践
|
||||
|
||||
## 📖 学习路径
|
||||
## 学习路径
|
||||
|
||||
### 初学者路径
|
||||
1. 从 [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]] 开始，理解核心论点
|
||||
2. 阅读 [[From-Weights-to-Context-to-Harness|从权重到上下文到 Harness]]，了解历史背景
|
||||
3. 深入三大外部化维度：[[Memory-Systems|记忆]]、[[Skill-Systems|技能]]、[[Agent-Protocols|协议]]
|
||||
4. 最后学习 [[Harness-Engineering|Harness 工程]] 如何将它们统一
|
||||
|
||||
1. 首先阅读 [[Harness-Engineering|Harness 工程]] 获得概览
|
||||
2. 然后阅读 [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] 了解个人采用路径
|
||||
3. 最后阅读 [[Building-Your-First-Harness|构建你的第一个 Harness]] 开始实践
|
||||
### 架构师路径
|
||||
1. 直接阅读 [[Harness-Engineering|Harness 工程]] 了解六大分析维度
|
||||
2. 参考 [[Externalization-in-LLM-Agents|外部化理论]] 作为理论基础
|
||||
3. 根据需要深入各模块细节
|
||||
|
||||
### 深入学习路径
|
||||
## 最新研究
|
||||
|
||||
1. 从 [[Anthropic-Harness-Design|Anthropic Harness 设计]] 开始了解前沿架构
|
||||
2. 深入研究 [[Context-Engineering|上下文工程]] 和 [[Architectural-Constraints|架构约束]]
|
||||
3. 学习 [[Self-Verification|自我验证]] 技术让智能体自我改进
|
||||
本知识库基于 2026 年 4 月发表的最新综述论文和实践报告，涵盖：
|
||||
- 记忆架构的四代演进（单片上下文 → 检索存储 → 分层编排 → 自适应系统）
|
||||
- 技能系统从工具使用到能力包的演变
|
||||
- 协议生态系统（MCP、A2A、ACP、ANP、A2UI 等）
|
||||
- Harness 工程的六大分析维度
|
||||
- 多 Agent 架构实践（Planner-Generator-Evaluator 三 Agent 系统）
|
||||
|
||||
---
|
||||
## 相关研究
|
||||
|
||||
## 🔗 快速导航
|
||||
|
||||
- [[Glossary|术语表]] - 40+ 核心概念的中英对照和解释
|
||||
- [概念目录](./concepts/) - 所有核心概念文章
|
||||
- [实践目录](./practices/) - 所有实践指南文章
|
||||
|
||||
---
|
||||
|
||||
## 📊 编译来源
|
||||
|
||||
本知识库基于以下权威来源编译：
|
||||
|
||||
1. **OpenAI** - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. **Anthropic** - Harness design for long-running application development
|
||||
3. **Martin Fowler** - Harness engineering for coding agent users
|
||||
4. **LangChain** - Improving Deep Agents with harness engineering
|
||||
5. **NxCode** - Harness Engineering: The Complete Guide
|
||||
6. **MiniMax** - MiniMax M2.7: Early Echoes of Self-Evolution
|
||||
7. **Mitchell Hashimoto** - My AI Adoption Journey
|
||||
|
||||
---
|
||||
|
||||
## 💡 关于 WikiLLM
|
||||
|
||||
WikiLLM 是一个利用 LLM 构建个人知识库的系统。本项目的核心原则是：
|
||||
|
||||
- **LLM 编写和维护所有 wiki 数据**；手动编辑很少见
|
||||
- **用户探索和查询被归档回 wiki** 以增强它
|
||||
- **系统专注于 markdown 文件和 Obsidian 兼容格式**
|
||||
- **图像被下载到本地** 以便 LLM 轻松引用
|
||||
|
||||
查看 [[Glossary|术语表]] 了解更多核心概念，或从 [[Harness-Engineering|Harness 工程]] 开始阅读！
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 自动生成*
|
||||
- 认知人工制品理论 (Norman, 1991)
|
||||
- 分布式认知 (Hutchins, 1995)
|
||||
- 互补策略 (Kirsh, 1995)
|
||||
- CoALA 架构
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 86 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 234 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 282 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 317 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 199 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 284 KiB After Width: | Height: | Size: 295 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 177 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 378 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 339 KiB |
|
Before Width: | Height: | Size: 7.1 MiB After Width: | Height: | Size: 7.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 234 KiB |
@@ -1,280 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta content = 'uft-8' name = 'charset'></meta>
|
||||
|
||||
<title>not found</title>
|
||||
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" /><script defer src="https://cloud.umami.is/script.js" data-website-id="eb12527f-b713-4afa-905a-8a50f8a7f157"></script>
|
||||
<link href = '/global.css' rel = 'stylesheet' type = 'text/css'></link>
|
||||
</head>
|
||||
|
||||
<body><header id = 'banner' style = 'background-image: url("/banner.png"); background-repeat: no-repeat'>
|
||||
|
||||
<div class = 'name-logo'><a href = 'https://martinfowler.com'><img src = '/mf-name-white.png'></img></a></div>
|
||||
<div class = 'search'>
|
||||
<!-- SiteSearch Google -->
|
||||
<form method='GET' action="https://www.google.com/search">
|
||||
<input type='hidden' name='ie' value='UTF-8'/>
|
||||
<input type='hidden' name='oe' value='UTF-8'/>
|
||||
<input class = 'field' type='text'
|
||||
name='q' size='15' maxlength='255' value=""/>
|
||||
<button class = 'button' type='submit'
|
||||
name='btnG' value=" " title = "Search"/>
|
||||
<input type='hidden' name='domains' value="martinfowler.com"/>
|
||||
<input type='hidden' name='sitesearch' value=""/>
|
||||
<input
|
||||
type='hidden' name='sitesearch' value="martinfowler.com"/>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<div class = 'menu-button navmenu-button'><a class = 'icon icon-bars' href = '#navmenu-bottom'></a></div>
|
||||
|
||||
<nav class = 'top-menu'>
|
||||
<ul>
|
||||
<li><a class = '' href = 'https://refactoring.com'>Refactoring</a></li>
|
||||
|
||||
<li><a class = '' href = '/agile.html'>Agile</a></li>
|
||||
|
||||
<li><a class = '' href = '/architecture'>Architecture</a></li>
|
||||
|
||||
<li><a class = '' href = '/aboutMe.html'>About</a></li>
|
||||
|
||||
<li><a class = 'tw' href = 'https://www.thoughtworks.com/engineering'>Thoughtworks</a></li>
|
||||
|
||||
<li><a class = 'icon icon-rss' href = '/feed.atom' title = 'feed'></a></li>
|
||||
|
||||
<li><a class = 'icon icon-twitter' href = 'https://www.twitter.com/martinfowler' title = 'Twitter stream'></a></li>
|
||||
|
||||
<li class = 'icon'><a href = 'https://toot.thoughtworks.com/@mfowler' title = 'Mastodon stream'><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor"><path d="M21.2595 13.9898C20.9852 15.4006 18.8033 16.9446 16.2974 17.2439C14.9907 17.3998 13.7041 17.5431 12.3321 17.4802C10.0885 17.3774 8.31809 16.9446 8.31809 16.9446C8.31809 17.163 8.33156 17.371 8.3585 17.5655C8.65019 19.7797 10.5541 19.9124 12.3576 19.9742C14.1779 20.0365 15.7987 19.5254 15.7987 19.5254L15.8735 21.1711C15.8735 21.1711 14.6003 21.8548 12.3321 21.9805C11.0814 22.0493 9.52849 21.9491 7.71973 21.4703C3.79684 20.432 3.12219 16.2504 3.01896 12.0074C2.98749 10.7477 3.00689 9.55981 3.00689 8.56632C3.00689 4.22771 5.84955 2.95599 5.84955 2.95599C7.2829 2.29772 9.74238 2.0209 12.2993 2H12.3621C14.919 2.0209 17.3801 2.29772 18.8133 2.95599C18.8133 2.95599 21.6559 4.22771 21.6559 8.56632C21.6559 8.56632 21.6916 11.7674 21.2595 13.9898ZM18.3029 8.9029C18.3029 7.82924 18.0295 6.97604 17.4805 6.34482C16.9142 5.71359 16.1726 5.39001 15.2522 5.39001C14.187 5.39001 13.3805 5.79937 12.8473 6.61819L12.3288 7.48723L11.8104 6.61819C11.2771 5.79937 10.4706 5.39001 9.40554 5.39001C8.485 5.39001 7.74344 5.71359 7.17719 6.34482C6.62807 6.97604 6.3547 7.82924 6.3547 8.9029V14.1562H8.43597V9.05731C8.43597 7.98246 8.88822 7.4369 9.79281 7.4369C10.793 7.4369 11.2944 8.08408 11.2944 9.36376V12.1547H13.3634V9.36376C13.3634 8.08408 13.8646 7.4369 14.8648 7.4369C15.7694 7.4369 16.2216 7.98246 16.2216 9.05731V14.1562H18.3029V8.9029Z"></path></svg>
|
||||
</a></li>
|
||||
|
||||
<li class = 'icon'><a href = 'https://www.linkedin.com/in/martin-fowler-com/' title = 'LinkedIn'><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor"><path d="M4.00098 3H20.001C20.5533 3 21.001 3.44772 21.001 4V20C21.001 20.5523 20.5533 21 20.001 21H4.00098C3.44869 21 3.00098 20.5523 3.00098 20V4C3.00098 3.44772 3.44869 3 4.00098 3ZM5.00098 5V19H19.001V5H5.00098ZM7.50098 9C6.67255 9 6.00098 8.32843 6.00098 7.5C6.00098 6.67157 6.67255 6 7.50098 6C8.3294 6 9.00098 6.67157 9.00098 7.5C9.00098 8.32843 8.3294 9 7.50098 9ZM6.50098 10H8.50098V17.5H6.50098V10ZM12.001 10.4295C12.5854 9.86534 13.2665 9.5 14.001 9.5C16.072 9.5 17.501 11.1789 17.501 13.25V17.5H15.501V13.25C15.501 12.2835 14.7175 11.5 13.751 11.5C12.7845 11.5 12.001 12.2835 12.001 13.25V17.5H10.001V10H12.001V10.4295Z"></path></svg>
|
||||
</a></li>
|
||||
|
||||
<li class = 'icon'><a href = 'https://bsky.app/profile/martinfowler.com' title = 'BlueSky'><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor"><path d="M12 11.3884C11.0942 9.62673 8.62833 6.34423 6.335 4.7259C4.13833 3.17506 3.30083 3.4434 2.75167 3.69256C2.11583 3.9784 2 4.95506 2 5.52839C2 6.10339 2.315 10.2367 2.52 10.9276C3.19917 13.2076 5.61417 13.9776 7.83917 13.7309C4.57917 14.2142 1.68333 15.4017 5.48083 19.6292C9.65833 23.9542 11.2058 18.7017 12 16.0392C12.7942 18.7017 13.7083 23.7651 18.4442 19.6292C22 16.0392 19.4208 14.2142 16.1608 13.7309C18.3858 13.9784 20.8008 13.2076 21.48 10.9276C21.685 10.2376 22 6.10256 22 5.52923C22 4.95423 21.8842 3.97839 21.2483 3.6909C20.6992 3.44256 19.8617 3.17423 17.665 4.72423C15.3717 6.34506 12.9058 9.62756 12 11.3884Z"></path></svg></a></li>
|
||||
</ul>
|
||||
</nav>
|
||||
</header>
|
||||
<nav id = 'top-navmenu'>
|
||||
<nav class = 'navmenu'>
|
||||
<div class = 'nav-head'> <div class = 'search'>
|
||||
<!-- SiteSearch Google -->
|
||||
<form method='GET' action="https://www.google.com/search">
|
||||
<input type='hidden' name='ie' value='UTF-8'/>
|
||||
<input type='hidden' name='oe' value='UTF-8'/>
|
||||
<input class = 'field' type='text'
|
||||
name='q' size='15' maxlength='255' value=""/>
|
||||
<button class = 'button' type='submit'
|
||||
name='btnG' value=" " title = "Search"/>
|
||||
<input type='hidden' name='domains' value="martinfowler.com"/>
|
||||
<input type='hidden' name='sitesearch' value=""/>
|
||||
<input
|
||||
type='hidden' name='sitesearch' value="martinfowler.com"/>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<div class = 'closediv'>
|
||||
<span class = 'close' title = 'close'></span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class = 'nav-body'>
|
||||
<div class = 'topics'>
|
||||
<h2>Topics</h2>
|
||||
|
||||
<p><a href = '/architecture'>Architecture</a></p>
|
||||
|
||||
<p><a href = 'https://refactoring.com'>Refactoring</a></p>
|
||||
|
||||
<p><a href = '/agile.html'>Agile</a></p>
|
||||
|
||||
<p><a href = '/delivery.html'>Delivery</a></p>
|
||||
|
||||
<p><a href = '/microservices'>Microservices</a></p>
|
||||
|
||||
<p><a href = '/data'>Data</a></p>
|
||||
|
||||
<p><a href = '/testing'>Testing</a></p>
|
||||
|
||||
<p><a href = '/dsl.html'>DSL</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'about'>
|
||||
<h2>about me</h2>
|
||||
|
||||
<p><a href = '/aboutMe.html'>About</a></p>
|
||||
|
||||
<p><a href = '/books'>Books</a></p>
|
||||
|
||||
<p><a href = '/faq.html'>FAQ</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'content'>
|
||||
<h2>content</h2>
|
||||
|
||||
<p><a href = '/videos.html'>Videos</a></p>
|
||||
|
||||
<p><a href = '/tags'>Content Index</a></p>
|
||||
|
||||
<p><a href = '/boardgames'>Board Games</a></p>
|
||||
|
||||
<p><a href = '/photos'>Photography</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'tw'>
|
||||
<h2>Thoughtworks</h2>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com'>Home</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/insights'>Insights</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/careers'>Careers</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/radar'>Radar</a></p>
|
||||
|
||||
<p><a href = 'https://www.thoughtworks.com/engineering'>Engineering</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'feeds'>
|
||||
<h2>follow</h2>
|
||||
|
||||
<p><a href = '/feed.atom'>RSS</a></p>
|
||||
|
||||
<p><a href = 'https://toot.thoughtworks.com/@mfowler'>Mastodon</a></p>
|
||||
|
||||
<p><a href = 'https://www.linkedin.com/in/martin-fowler-com/'>LinkedIn</a></p>
|
||||
|
||||
<p><a href = 'https://bsky.app/profile/martinfowler.com'>Bluesky</a></p>
|
||||
|
||||
<p><a href = 'https://www.twitter.com/martinfowler'>X</a></p>
|
||||
|
||||
<p><a href = 'https://boardgamegeek.com/blog/13064/martins-7th-decade'>BGG</a></p>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</nav>
|
||||
|
||||
<main><h1 id="section">404</h1>
|
||||
|
||||
<p>I’m afraid this is not the document you’re looking for. Try using the
|
||||
search box above, and good luck.</p>
|
||||
</main>
|
||||
|
||||
<nav id = 'bottom-navmenu'>
|
||||
<nav class = 'navmenu'>
|
||||
<div class = 'nav-head'> <div class = 'search'>
|
||||
<!-- SiteSearch Google -->
|
||||
<form method='GET' action="https://www.google.com/search">
|
||||
<input type='hidden' name='ie' value='UTF-8'/>
|
||||
<input type='hidden' name='oe' value='UTF-8'/>
|
||||
<input class = 'field' type='text'
|
||||
name='q' size='15' maxlength='255' value=""/>
|
||||
<button class = 'button' type='submit'
|
||||
name='btnG' value=" " title = "Search"/>
|
||||
<input type='hidden' name='domains' value="martinfowler.com"/>
|
||||
<input type='hidden' name='sitesearch' value=""/>
|
||||
<input
|
||||
type='hidden' name='sitesearch' value="martinfowler.com"/>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<div class = 'closediv'>
|
||||
<span class = 'close' title = 'close'></span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class = 'nav-body'>
|
||||
<div class = 'topics'>
|
||||
<h2>Topics</h2>
|
||||
|
||||
<p><a href = '/architecture'>Architecture</a></p>
|
||||
|
||||
<p><a href = 'https://refactoring.com'>Refactoring</a></p>
|
||||
|
||||
<p><a href = '/agile.html'>Agile</a></p>
|
||||
|
||||
<p><a href = '/delivery.html'>Delivery</a></p>
|
||||
|
||||
<p><a href = '/microservices'>Microservices</a></p>
|
||||
|
||||
<p><a href = '/data'>Data</a></p>
|
||||
|
||||
<p><a href = '/testing'>Testing</a></p>
|
||||
|
||||
<p><a href = '/dsl.html'>DSL</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'about'>
|
||||
<h2>about me</h2>
|
||||
|
||||
<p><a href = '/aboutMe.html'>About</a></p>
|
||||
|
||||
<p><a href = '/books'>Books</a></p>
|
||||
|
||||
<p><a href = '/faq.html'>FAQ</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'content'>
|
||||
<h2>content</h2>
|
||||
|
||||
<p><a href = '/videos.html'>Videos</a></p>
|
||||
|
||||
<p><a href = '/tags'>Content Index</a></p>
|
||||
|
||||
<p><a href = '/boardgames'>Board Games</a></p>
|
||||
|
||||
<p><a href = '/photos'>Photography</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'tw'>
|
||||
<h2>Thoughtworks</h2>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com'>Home</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/insights'>Insights</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/careers'>Careers</a></p>
|
||||
|
||||
<p><a href = 'https://thoughtworks.com/radar'>Radar</a></p>
|
||||
|
||||
<p><a href = 'https://www.thoughtworks.com/engineering'>Engineering</a></p>
|
||||
</div>
|
||||
|
||||
<div class = 'feeds'>
|
||||
<h2>follow</h2>
|
||||
|
||||
<p><a href = '/feed.atom'>RSS</a></p>
|
||||
|
||||
<p><a href = 'https://toot.thoughtworks.com/@mfowler'>Mastodon</a></p>
|
||||
|
||||
<p><a href = 'https://www.linkedin.com/in/martin-fowler-com/'>LinkedIn</a></p>
|
||||
|
||||
<p><a href = 'https://bsky.app/profile/martinfowler.com'>Bluesky</a></p>
|
||||
|
||||
<p><a href = 'https://www.twitter.com/martinfowler'>X</a></p>
|
||||
|
||||
<p><a href = 'https://boardgamegeek.com/blog/13064/martins-7th-decade'>BGG</a></p>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</nav>
|
||||
<footer id='page-footer'>
|
||||
<div class='tw-logo'>
|
||||
<a href='https://www.thoughtworks.com/engineering'>
|
||||
<img src='/thoughtworks_white.png'>
|
||||
</a>
|
||||
</div>
|
||||
<div class='menu-button'>
|
||||
<div class='icon-bars navmenu-button'></div>
|
||||
</div>
|
||||
<div class='copyright'>
|
||||
<p>© Martin Fowler | <a href="/aboutMe.html#disclosures">Disclosures</a></p>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<script src = '/jquery-1.11.3.min.js' type = 'text/javascript'></script>
|
||||
|
||||
<script src = '/mfcom.js' type = 'text/javascript'></script>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 200 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 175 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 198 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 305 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 286 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.6 MiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 139 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 395 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 216 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 966 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 671 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 214 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 246 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 208 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 188 KiB |
@@ -0,0 +1,12 @@
|
||||
raw_path hash last_modified wiki_paths compile_time status
|
||||
raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md sha256:initial 2026-04-11 wiki/concepts/Externalization-in-LLM-Agents.md,wiki/concepts/Harness-Engineering.md,wiki/concepts/Memory-Systems.md,wiki/concepts/Skill-Systems.md,wiki/concepts/Agent-Protocols.md,wiki/concepts/From-Weights-to-Context-to-Harness.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Harness design for long-running application development.md sha256:initial 2026-04-11 wiki/practices/Long-Running-Harness-Design.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/工程技术：在智能体优先的世界中利用 Codex.md sha256:initial 2026-04-11 wiki/practices/OpenAI-Codex-Harness-Engineering.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/My AI Adoption Journey.md sha256:initial 2026-04-11 wiki/practices/Mitchellh-AI-Adoption-Journey.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Harness engineering for coding agent users.md sha256:initial 2026-04-11 wiki/concepts/Harness-Engineering-for-Coding-Agent-Users.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Improving Deep Agents with harness engineering.md sha256:initial 2026-04-11 wiki/practices/LangChain-Harness-Engineering.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Scaling Managed Agents Decoupling the brain from the hands.md sha256:initial 2026-04-11 wiki/practices/Managed-Agents-Decoupling-Brain-from-Hands.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/MiniMax M2.7 开启模型的自我进化.md sha256:initial 2026-04-11 wiki/practices/MiniMax-M27-Self-Evolution.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Harness Engineering The Complete Guide to Building Systems That Make AI Agents Actually Work (2026).md sha256:initial 2026-04-11 wiki/concepts/Harness-Engineering-Complete-Guide.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Harness Engineering - first thoughts.md sha256:initial 2026-04-11 wiki/concepts/Harness-Engineering-First-Thoughts.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
raw/Meta-Harness End-to-End Optimization of Model Harnesses.md sha256:initial 2026-04-11 wiki/concepts/Meta-Harness.md,wiki/INDEX.md,wiki/Glossary.md 2026-04-11 success
|
||||
|
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: "智能体协议"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "协议"
|
||||
- "外部化"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 智能体协议
|
||||
|
||||
**协议外部化**解决了智能体的交互负担问题。它定义了用于发现、调用、委托和权限管理的显式机器可读契约，而不是依赖临时提示级别的与工具、服务和其他智能体的协调。
|
||||
|
||||
## 协议外部化的四大维度
|
||||
|
||||
|
||||
|
||||
### 1. 调用语法
|
||||
|
||||
每个工具调用、API 请求或委托消息都需要一种格式：参数名称、类型、排序和返回结构。
|
||||
|
||||
- **没有协议**，模型必须在每次调用时推断或重新发明这种语法
|
||||
- **协议外部化**将其化为模式和类型化接口，因此模型填充字段而不是猜测语法
|
||||
|
||||
### 2. 生命周期语义
|
||||
|
||||
多步交互需要协调：谁接下来行动，允许什么状态转换，任务何时完成或失败。
|
||||
|
||||
- **协议外部化**将这些排序规则化为显式状态机或事件流
|
||||
- **从模型的推理负担中移除它们**
|
||||
|
||||
### 3. 权限和信任边界
|
||||
|
||||
现实世界的智能体行为受到谁被授权、数据可以流向哪里以及必须产生什么证据的限制。
|
||||
|
||||
- **协议外部化**将这些约束化为可检查的规则，运行时可以强制执行
|
||||
- **而不是依赖模型自我监督**
|
||||
|
||||
### 4. 发现元数据
|
||||
|
||||
在智能体可以与工具或另一个智能体交互之前，它必须知道有哪些能力可用以及如何到达它们。
|
||||
|
||||
- **协议外部化**将此发现问题化为注册表、能力卡和模式端点
|
||||
- **用可查询的元数据替换隐含的提示嵌入知识**
|
||||
|
||||
## 为什么协议重要
|
||||
|
||||
Agent 协议的重要性直接源于它们外部化的负担：没有它们，每次交互部分都是关于格式、合法性和协调的推理问题。
|
||||
|
||||
### 统一的交互标准
|
||||
|
||||
协议为工具、智能体和前端提供了用于发现、调用、移交和状态交换的共享语法。
|
||||
|
||||
- **没有该层**，生态系统会分裂为局部提示加解析器集成
|
||||
- **标准化交互使互操作性成为设计属性**，而不是幸运的意外
|
||||
- **稳定多智能体协作的先决条件**
|
||||
|
||||
### 改进的安全性、治理和可审计性
|
||||
|
||||
一旦智能体在现实环境中运行，问题不仅是它们是否可以行动，还有这些行动是否保持有界、可检查和可恢复。
|
||||
|
||||
- **协议通过使权限、身份、执行轨迹、失败状态和责任边界显式化来提供帮助**
|
||||
- **将以前隐含的粘合逻辑转化为运行时可以验证和操作员可以审计的东西**
|
||||
|
||||
### 减少的供应商依赖
|
||||
|
||||
开放的交互契约还保留了架构灵活性。
|
||||
|
||||
- **如果系统在协议层累积能力**，而不是在供应商特定的接口内，模型、供应商和运行时组件可以用更少的重新布线交换
|
||||
- **协议不仅是工程便利；它们是智能体生态系统随时间保持可移植和可演化的机制的一部分**
|
||||
|
||||
## Agent 协议系列
|
||||
|
||||
### 1. Agent-Tool 协议
|
||||
|
||||
Agent-Tool 协议是最早成熟的协议系列之一，因为工具访问是接口碎片化首先出现的地方。
|
||||
|
||||
**MCP (Model Context Protocol)** 是最清晰的代表：
|
||||
- 提供标准化方式让智能体发现工具、检查其模式并跨异构服务调用它们
|
||||
- 通过 JSON-RPC 2.0 公开工具和上下文资源
|
||||
- 将工具生态系统与模型供应商特定的函数调用格式解耦
|
||||
|
||||
### 2. Agent-Agent 协议
|
||||
|
||||
一旦多个智能体协作，交互本身就成为系统问题。Agent-Agent 协议定义能力如何被发现、任务如何被委托、进度和部分状态如何被交换以及结果如何返回给调用者。
|
||||
|
||||
**代表性协议**：
|
||||
- **A2A** - 标准化通过 Agent Card 等人工制品进行的能力发现，并支持异构智能体之间的面向任务的通信、状态更新、协商和流式进度
|
||||
- **ACP** - 通过熟悉的 REST/HTTP 模式强调轻量级采用
|
||||
- **ANP** - 推动相反方向，目标是具有去中心化身份、跨域发现和安全端到端通信的开放、互联网级互操作性
|
||||
|
||||
### 3. Agent-User 协议
|
||||
|
||||
Agent-User 协议形式化了智能体运行时和面向用户的系统之间的边界。
|
||||
|
||||
**两个主要方向**：
|
||||
1. **A2UI** - 允许智能体以约束的声明格式描述 UI 结构，主机应用程序可以跨平台安全地呈现
|
||||
2. **AG-UI** - 标准化类型化执行事件，如运行开始、文本发射、工具调用参数、工具调用结果、完成和错误
|
||||
|
||||
### 4. 其他协议
|
||||
|
||||
除了一般交互系列外，一些协议还针对通用接口不够的高风险垂直工作流。
|
||||
|
||||
- **UCP (Universal Commerce Protocol)** - 为智能体商务做这件事，标准化目录、请求和结账流程
|
||||
- **AP2 (Agent Payments Protocol)** - 为支付做同样的事，强调授权、签名、可审计性和承载证明的事务对象
|
||||
|
||||
## Harness 工程中的 Agent 协议
|
||||
|
||||
如果上面的调查显示哪些交互负担在生态系统中被外部化，Harness 工程显示这些协议表面一旦智能体嵌入运行时如何成为运行智能体的一部分。
|
||||
|
||||
### 意图捕获和规范化
|
||||
|
||||
意图捕获和规范化是这些表面中的第一个。该层的工作是将模型产生的语言转换为运行时可以验证和采取行动的显式命令或事件。
|
||||
|
||||
### 能力发现和工具描述
|
||||
|
||||
能力发现和工具描述形成第二个表面。在较旧的系统中，可用工具的知识通常部分存在于提示中，部分存在于开发者假设中。协议化发现用显式元数据替换了这一点。
|
||||
|
||||
### 会话和生命周期管理
|
||||
|
||||
Harness 协议还需要显式的会话和生命周期管理，因为长视野智能体不会作为孤立的单调用运行。
|
||||
|
||||
## 协议作为认知人工制品
|
||||
|
||||
协议为交互执行这一点。没有它们，每个外部行动部分都是自然语言推理问题：模型必须推断预期的操作，猜测正确的格式，重建可接受的约束，并希望接收系统正确解释结果。
|
||||
|
||||
**协议用有界的结构化任务替换了那种开放式推理**：
|
||||
- 填充类型化字段
|
||||
- 遵循声明的状态转换
|
||||
- 接收结构化反馈
|
||||
|
||||
> **模型仍然需要关于是否以及何时行动的判断，但它不再需要在每个步骤上重新发明交互的语法和语义。**
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
@@ -1,142 +0,0 @@
|
||||
---
|
||||
title: Anthropic Harness 设计
|
||||
tags: [核心概念, 架构, 智能体]
|
||||
source: [Anthropic]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# Anthropic Harness 设计
|
||||
|
||||
**Anthropic Harness 设计**是 Anthropic 团队 Prithvi Rajasekaran 提出的多智能体架构，用于长时间运行的应用开发。该设计受生成对抗网络（GAN）启发，使用**生成器**和**评估器**智能体的组合。
|
||||
|
||||
## 问题背景
|
||||
|
||||
### 朴素实现的不足
|
||||
|
||||
之前的工作已经表明，Harness 设计对长时间运行的智能体编码的有效性有重大影响。但对于更复杂的任务，智能体仍然倾向于随着时间推移偏离轨道。观察到两种常见的失败模式：
|
||||
|
||||
1. **上下文窗口填充和"上下文焦虑"**：模型在冗长任务上随着上下文窗口填充而失去连贯性。一些模型还表现出"上下文焦虑"，当它们接近认为的上下文限制时会提前结束工作。
|
||||
|
||||
2. **自我评估问题**：当被要求评估它们自己生成的作品时，智能体倾向于自信地赞扬作品——即使，对于人类观察者来说，质量明显平庸。这个问题对于主观任务（如设计）特别明显，没有二进制检查相当于可验证的软件测试。
|
||||
|
||||
## 核心架构
|
||||
|
||||
### 三智能体系统
|
||||
|
||||
Anthropic 最终构建了一个三智能体系统，每个智能体解决先前运行中观察到的特定差距：
|
||||
|
||||
| 角色 | 职责 |
|
||||
|------|------|
|
||||
| **Planner（规划者）** | 将简单的 1-4 句话提示扩展为完整的产品规格 |
|
||||
| **Generator（生成者）** | 一次一个功能地实现规格，带有 git 版本控制 |
|
||||
| **Evaluator（评估器）** | 使用 Playwright MCP 测试运行中的应用，分级并提供详细反馈 |
|
||||
|
||||
### 上下文重置 vs 压缩
|
||||
|
||||
**上下文重置**：清空上下文窗口并启动一个新的智能体，结合携带先前智能体状态和下一步的结构化交接。
|
||||
|
||||
**上下文压缩**：将对话的早期部分就地摘要，以便同一个智能体可以在缩短的历史上继续。
|
||||
|
||||
虽然压缩保留了连续性，但它没有给智能体一个干净的状态，这意味着上下文焦虑仍然可能存在。重置提供了一个干净的状态，但代价是交接工件必须有足够的状态让下一个智能体干净地接手工作。
|
||||
|
||||
在早期测试中，发现 Claude Sonnet 4.5 表现出足够强的上下文焦虑，以至于仅靠压缩不足以实现良好的长任务性能，因此上下文重置成为 Harness 设计的必要条件。
|
||||
|
||||
## 前端设计：使主观质量可分级
|
||||
|
||||
### 两个洞见
|
||||
|
||||
1. 虽然美学不能完全简化为分数——而且个人品味总是会变化——但它们可以通过编码设计原则和偏好的分级标准来改善。
|
||||
2. 通过将前端生成与前端分级分离，可以创建一个推动生成器朝着更强输出发展的反馈循环。
|
||||
|
||||
### 四个分级标准
|
||||
|
||||
| 标准 | 描述 |
|
||||
|------|------|
|
||||
| **设计质量** | 设计感觉像是一个连贯的整体而不是部分的集合吗？ |
|
||||
| **原创性** | 是否有自定义决策的证据，还是只是模板布局、库默认值和 AI 生成的模式？ |
|
||||
| **工艺** | 技术执行：排版层次结构、间距一致性、色彩和谐、对比度。 |
|
||||
| **功能性** | 独立于美学的可用性。用户能理解界面做什么吗？ |
|
||||
|
||||
强调设计质量和原创性超过工艺和功能性。Claude 已经默认在工艺和功能性上得分很高，因为所需的技术能力往往自然而然地出现在模型中。但在设计和原创性上，Claude 经常产生充其量是乏味的输出。
|
||||
|
||||
### 生成-评估循环
|
||||
|
||||
构建在 Claude Agent SDK 上的循环：
|
||||
|
||||
1. 生成器智能体首先根据用户提示创建 HTML/CSS/JS 前端
|
||||
2. 给予评估器 Playwright MCP，让它在评分每个标准并编写详细批评之前直接与实时页面交互
|
||||
3. 该反馈流回生成器作为下一次迭代的输入
|
||||
4. 每次生成运行 5 到 15 次迭代
|
||||
|
||||
在每次评估后，指示生成器做出战略决策：如果分数趋势良好则改进当前方向，或者如果方法不起作用则转向完全不同的美学。
|
||||
|
||||
## 扩展到全栈编码
|
||||
|
||||
### 架构演变
|
||||
|
||||
Opus 4.5 基本上自行消除了上下文焦虑行为，因此可以完全从 Harness 中删除上下文重置。智能体作为一个连续会话在整个构建中运行，Claude Agent SDK 的自动压缩处理沿途的上下文增长。
|
||||
|
||||
### 冲刺契约
|
||||
|
||||
在每个冲刺之前，生成器和评估器协商一个**冲刺契约**：在编写任何代码之前就该工作块的"完成"看起来像什么达成一致。
|
||||
|
||||
这存在是因为产品规格故意是高级的，需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器正在构建正确的东西。两者迭代直到达成一致。
|
||||
|
||||
### 结果对比
|
||||
|
||||
使用"创建一个带有关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作器"提示进行的测试：
|
||||
|
||||
| Harness | 持续时间 | 成本 |
|
||||
|---------|---------|------|
|
||||
| Solo | 20 分钟 | $9 |
|
||||
| 完整 Harness | 6 小时 | $200 |
|
||||
|
||||
Harness 贵了 20 多倍，但输出质量的差异立即显而易见。
|
||||
|
||||
## Harness 简化迭代
|
||||
|
||||
### 移除冲刺构造
|
||||
|
||||
从 Harness 中完全移除了冲刺构造。保留了规划器和评估器，因为每个都继续增加明显的价值。将评估器移动到运行结束时的单次通过，而不是每个冲刺分级。
|
||||
|
||||
### 模型改进的影响
|
||||
|
||||
Opus 4.6 的发布提供了进一步减少 Harness 复杂性的动力。Opus 4.6 更仔细地规划、更长时间地维持智能体任务、可以在更大的代码库中更可靠地操作，并且具有更好的代码审查和调试技能来捕捉自己的错误。它还在长上下文检索方面有了实质性改进。
|
||||
|
||||
### 更新后的 Harness 结果
|
||||
|
||||
使用"使用 Web Audio API 在浏览器中构建功能完整的 DAW"提示进行的测试：
|
||||
|
||||
- 总持续时间：约 4 小时
|
||||
- 总成本：$124.70
|
||||
|
||||
大部分时间花在构建器上，它在没有 Opus 4.5 所需的冲刺分解的情况下连贯运行了两个多小时。
|
||||
|
||||
## 关键经验教训
|
||||
|
||||
随着模型继续改进，可以大致期望它们能够工作更长时间，处理更复杂的任务。在某些情况下，这将意味着随着时间推移，模型周围的支架变得不那么重要，开发人员可以等待下一个模型并看到某些问题自行解决。另一方面，模型越好，开发能够实现超出模型在基线水平所能做到的复杂任务的 Harness 的空间就越大。
|
||||
|
||||
有几个经验教训值得向前推进：
|
||||
|
||||
1. 用你正在构建的模型进行实验总是好的做法
|
||||
2. 在处理更复杂的任务时，有时可以通过分解任务并将专门的智能体应用于问题的每个方面来获得提升
|
||||
3. 当新模型落地时，重新检查 Harness 通常是好的做法，剥离那些不再对性能有负载作用的部分，并添加新部分以实现以前可能无法实现的更大能力
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Generator-Evaluator Loop|生成-评估循环]]
|
||||
- [[Context Reset|上下文重置]]
|
||||
- [[Planner|规划者]]
|
||||
- [[Generator|生成者]]
|
||||
- [[Evaluator|评估者]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. Anthropic - Harness design for long-running application development
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译*
|
||||
@@ -1,106 +0,0 @@
|
||||
---
|
||||
title: 架构约束
|
||||
tags: [核心概念, 架构, Harness]
|
||||
source: [OpenAI, Martin Fowler, NxCode]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 架构约束
|
||||
|
||||
**架构约束**（Architectural Constraints）是[[Harness-Engineering|Harness 工程]]的三大支柱之一。这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。
|
||||
|
||||
## 核心思想
|
||||
|
||||
### 约束反而提升生产力
|
||||
|
||||
矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
|
||||
### 为智能体优化代码库可读性
|
||||
|
||||
由于代码仓库完全由智能体生成，因此首先针对 Codex 的可读性进行了优化。就像团队会努力提升代码对新入职工程师的可导航性一样，人类工程师的目标也是让智能体能够直接从代码仓库推理出完整的业务领域。
|
||||
|
||||
从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问。代码仓库本地的、已版本化的工件（例如，代码、Markdown、模式、可执行计划）就是它所能看到的全部。
|
||||
|
||||
## 分层领域架构
|
||||
|
||||
OpenAI 围绕一个严格的架构模型构建了应用。每个业务领域都划分为一组固定的层，依赖方向经过严格验证，并且仅允许有限的一组边。这些约束是通过自定义的 linter（当然是由 Codex 生成的！）和结构测试机械地强制执行的。
|
||||
|
||||
|
||||
|
||||
### 依赖分层规则
|
||||
|
||||
在每个业务领域内（例如应用设置），代码只能"向前"依赖于一组固定的层：
|
||||
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
|
||||
横切关注点（认证、连接器、遥测、功能标志）通过一个单一的显式接口进入：Providers。其他任何内容都不被允许，并将通过自动化方式强制执行。
|
||||
|
||||
这种架构通常要等到你拥有数百名工程师时才会推迟。对于编码智能体来说，这是一个早期的先决条件：有了约束，速度才不会下降，架构才不会漂移。
|
||||
|
||||
## 约束强制执行工具
|
||||
|
||||
### 1. 确定性 Linters
|
||||
|
||||
自定义规则，自动标记违规。由于这些 lint 是自定义的，编写错误信息时会在智能体情境中注入修复指令。
|
||||
|
||||
在以人为本的工作流程中，这些规则可能会让人感到迂腐或束缚。有了智能体，它们就成了倍增器：一旦编码，它们就能立即应用于所有地方。
|
||||
|
||||
### 2. 基于 LLM 的审计员
|
||||
|
||||
审查其他智能体代码的架构合规性的智能体。
|
||||
|
||||
### 3. 结构测试
|
||||
|
||||
像 ArchUnit，但专门用于 AI 生成的代码。
|
||||
|
||||
### 4. 预提交钩子
|
||||
|
||||
在提交任何代码前的自动检查。
|
||||
|
||||
## 品味不变式
|
||||
|
||||
OpenAI 团队辅以一小组"品味不变式"。例如：
|
||||
|
||||
- 通过自定义 lint 静态地强制执行结构化日志记录
|
||||
- 模式和类型的命名约定
|
||||
- 文件大小限制
|
||||
- 特定平台的可靠性要求
|
||||
|
||||
## 明确界限
|
||||
|
||||
同时，还明确指出了哪些地方需要限制，哪些地方不需要限制。这类似于领导一个大型工程平台组织：在中央层面强制执行边界，在本地层面允许自主权。你非常重视界限、正确性和可重复性。在这些边界内，你允许团队或智能体在解决方案的表达方式上拥有很大的自由。
|
||||
|
||||
生成的代码不总是符合人类的风格偏好，这也没关系。只要输出是正确的、可维护的，并且对未来的智能体运行而言清晰易读，就可以算作达标。
|
||||
|
||||
## 依赖选择
|
||||
|
||||
这一框架明确了许多取舍。倾向于选择那些可以完全内化于在仓库中进行推理的依赖项和抽象。对智能体来说，通常被称为"枯燥"的技术，由于其可组合性、API 稳定性和在训练集里的表现，往往更容易建立模型。
|
||||
|
||||
在某些情况下，让智能体重新实现部分功能子集比绕过公共库中不透明的上游行为更便宜。例如，OpenAI 团队没有引入通用的 p-limit 风格包，而是投入使用了他们自己的带并发的 map 辅助函数：它与他们的 OpenTelemetry 仪表紧密集成，具备 100% 的测试覆盖率，并且其行为完全符合他们的运行时预期。
|
||||
|
||||
将系统的更多部分转化为智能体可以检查、验证并直接修改的形式，可以直接提高杠杆效应——这不仅适用于 Codex，也适用于其他智能体也在参与代码库的开发。
|
||||
|
||||
## 强制执行不变量
|
||||
|
||||
仅靠文档本身，是没法保持完全由智能体生成的代码库的连贯性的。通过强制执行不变量，而非对实施过程进行微观管理，令智能体能够快速交付，而且不会削弱基础。例如，要求 Codex 在边界处解析数据形状，但不规定具体实现方式（模型似乎偏好 Zod，但没有指定特定库）。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Entropy Management|熵管理]]
|
||||
- [[Layered Domain Architecture|分层领域架构]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. Martin Fowler - Harness engineering for coding agent users
|
||||
3. NxCode - Harness Engineering: The Complete Guide
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -1,124 +0,0 @@
|
||||
---
|
||||
title: 上下文工程
|
||||
tags: [核心概念, 上下文, Harness]
|
||||
source: [OpenAI, Anthropic, LangChain]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 上下文工程
|
||||
|
||||
**上下文工程**（Context Engineering）是[[Harness-Engineering|Harness 工程]]的三大支柱之一，专注于确保智能体在正确的时间获得正确的信息。
|
||||
|
||||
## 核心原则
|
||||
|
||||
### 给地图，而不是一千页说明书
|
||||
|
||||
OpenAI 团队学到的最早经验之一很简单：要给 Codex 的是一张地图，而不是一本 1,000 页的说明书。
|
||||
|
||||
他们尝试了"一个大型的 AGENTS.md 方法。可想而知，这是一次失败的尝试：
|
||||
|
||||
- **上下文是一种稀缺资源**：一个巨大的指令文件会挤掉任务、代码和相关文档——因此智能体要么会错过关键约束条件，要么开始针对错误的约束条件进行优化。
|
||||
- **过多的指导反而变得无效**：当一切都"重要"时，一切都不重要了。智能体最终会在本地进行模式匹配，而不是有意识地进行导航。
|
||||
- **它会立即腐烂**：一本庞杂的手册会变成陈旧规则的坟场。智能体无法判断哪些信息仍然有效，一旦人类停止维护它，此文件就会悄然成为一个颇具吸引力的麻烦源头。
|
||||
- **这很难核实**：单个 blob 不适合进行机械检查（覆盖率、新鲜度、所有权、交叉链接），因此漂移是不可避免的。
|
||||
|
||||
因此，他们不再将 AGENTS.md 视为百科全书，而是将其视为内容目录。
|
||||
|
||||
## 静态上下文与动态上下文
|
||||
|
||||
### 静态上下文
|
||||
|
||||
静态上下文是仓库中不会频繁变化的文档和规范：
|
||||
|
||||
- **仓库本地文档**：架构规范、API 契约、风格指南
|
||||
- **AGENTS.md 或 CLAUDE.md 文件**：编码项目特定规则
|
||||
- **交叉链接设计文档**：由 linter 验证的设计文档
|
||||
|
||||
### 动态上下文
|
||||
|
||||
动态上下文是随时间变化的运行时信息：
|
||||
|
||||
- **可观测性数据**：日志、指标、追踪——智能体可访问
|
||||
- **目录结构映射**：智能体启动时的目录映射
|
||||
- **CI/CD 流水线状态**：测试结果和流水线状态
|
||||
|
||||
## 关键规则
|
||||
|
||||
**从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。**
|
||||
|
||||
存储在 Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**
|
||||
|
||||
### 渐进式披露
|
||||
|
||||
这个框架实现了渐进式披露：智能体从一个小而稳定的切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。
|
||||
|
||||
OpenAI 团队严格执行这一点。专职的 linter 和 CI 作业会验证知识库的更新状况、是否已交叉链接且结构正确。一个定期运行的"doc-gardening"智能体会扫描那些不再反映真实代码行为的过时或废弃文档，并发起修复用的 Pull Request。
|
||||
|
||||
## 实践中的上下文工程
|
||||
|
||||
### OpenAI 的知识库布局
|
||||
|
||||
```
|
||||
AGENTS.md
|
||||
ARCHITECTURE.md
|
||||
docs/
|
||||
├── design-docs/
|
||||
│ ├── index.md
|
||||
│ ├── core-beliefs.md
|
||||
│ └── ...
|
||||
├── exec-plans/
|
||||
│ ├── active/
|
||||
│ ├── completed/
|
||||
│ └── tech-debt-tracker.md
|
||||
├── generated/
|
||||
│ └── db-schema.md
|
||||
├── product-specs/
|
||||
│ ├── index.md
|
||||
│ ├── new-user-onboarding.md
|
||||
│ └── ...
|
||||
├── references/
|
||||
│ ├── design-system-reference-llms.txt
|
||||
│ ├── nixpacks-llms.txt
|
||||
│ ├── uv-llms.txt
|
||||
│ └── ...
|
||||
├── DESIGN.md
|
||||
├── FRONTEND.md
|
||||
├── PLANS.md
|
||||
├── PRODUCT_SENSE.md
|
||||
├── QUALITY_SCORE.md
|
||||
├── RELIABILITY.md
|
||||
└── SECURITY.md
|
||||
```
|
||||
|
||||
设计文档已被编目和索引，其中包括验证状态和一套核心理念，定义了智能体优先的操作原则。架构文档提供域和包分层的顶层地图。一份高质量的文档会对每个产品领域和架构层进行评分，并随着时间的推移追踪差距。
|
||||
|
||||
计划被视为一流的工件。临时轻量计划用于小幅变更，而复杂工作则记录在执行计划中，并附带进度和决策日志，这些日志会被提交到代码仓库。活跃计划、已完成计划和已知的技术债务都已进行版本控制并集中存放，使智能体能够在不依赖外部情境的情况下运行。
|
||||
|
||||
### LangChain 的 LocalContextMiddleware
|
||||
|
||||
LangChain 使用 `LocalContextMiddleware` 在智能体启动时运行，映射 `cwd` 和其他父+子目录。他们运行 `bash` 命令来查找工具如 `Python` 安装。上下文发现和搜索容易出错，因此注入上下文减少了这个错误表面并帮助**将智能体引导到其环境中。**
|
||||
|
||||
## 将更多情境推送到仓库中
|
||||
|
||||
随着时间的推移，需要将越来越多的情境推送到仓库中。那次让团队在架构模式上达成一致的 Slack 讨论？如果智能体无法发现它，那么它就会像迟了三个月入职的新员工一样，对其一无所知。
|
||||
|
||||
为 Codex 提供更多情境意味着要组织和展示正确的信息，好令智能体能够基于这些信息进行推理，而不是用临时指令使其不堪重负。就像你会在产品原则、工程规范和团队文化（包括表情符号偏好）方面为新队友提供引导一样，将这些信息提供给智能体会带来更一致的输出。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Context Reset|上下文重置]]
|
||||
- [[Context Anxiety|上下文焦虑]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. LangChain - Improving Deep Agents with harness engineering
|
||||
3. Anthropic - Effective context engineering for AI agents
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: "LLM Agent 中的外部化"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "外部化"
|
||||
- "Harness工程"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# LLM Agent 中的外部化
|
||||
|
||||
**外部化 (Externalization)** 是 LLM Agent 设计的核心组织原则。它指的是将认知负担从模型的内部计算逐步迁移到持久、可检查和可重用的外部结构中的过程。
|
||||
|
||||
## 核心论点
|
||||
|
||||
本文的中心论点是：**外部化是统一近期 LLM Agent 在记忆、技能、协议和 Harness 工程方面进展的过渡逻辑**。
|
||||
|
||||
这不仅仅是一个关于工程便利性的主张，更是一个关于可靠智能体来源的主张：可靠的智能体不仅来自更强大的模型，还来自对任务需求的系统性重组，使得内部能力和外部基础设施共同覆盖所需的全部能力范围。
|
||||
|
||||
## 人类认知外部化的平行
|
||||
|
||||
人类文明史可以被解读为认知外部化的历史：
|
||||
|
||||
1. **语言** - 将私人思想转化为可共享的符号形式
|
||||
2. **文字** - 将知识从脆弱的生物记忆转移到持久的物质记录
|
||||
3. **印刷术** - 在社会规模上机械化知识的再生产
|
||||
4. **数字计算** - 将算术和符号操作从神经劳动转移到可编程机器
|
||||
|
||||
在这些转变中，关键的变化不是人类在没有人工制品的情况下能力下降了，而是人工制品通过将选定的负担向外转移，释放了有限的内部资源用于规划、抽象和创造力。
|
||||
|
||||
## 认知人工制品理论
|
||||
|
||||
这一视角在**认知人工制品 (cognitive artifacts)** 思想中有着自然的理论锚点。中心洞见是：外部辅助工具不仅仅是放大不变的内部能力，它们经常改变任务本身。
|
||||
|
||||
- **购物清单** 不扩展生物记忆容量，它将困难的回忆问题转化为识别问题
|
||||
- **地图** 不简单地使导航"更强"，它将隐藏的空间关系转化为可见的结构
|
||||
|
||||
人工制品的力量在于**表征转换**：它重组了问题，使智能体能够用它已经拥有的能力更可靠地解决问题。
|
||||
|
||||
## LLM Agent 的三大外部化维度
|
||||
|
||||
|
||||
|
||||
LLM Agent 通过三个不同但相互耦合的外部化维度实现可靠的智能：
|
||||
|
||||
### 1. 记忆系统：跨时间外部化状态
|
||||
|
||||
记忆系统允许积累的知识——用户偏好、先前轨迹、已解决的歧义、领域事实——在单个会话之外持续存在，并在相关时被选择性检索。
|
||||
|
||||
**核心转换**：从回忆到识别——智能体不再需要从潜在权重中再生过去的知识；它从持久、可搜索的存储中检索。
|
||||
|
||||
记忆的四个维度：
|
||||
- **工作上下文** - 当前任务的实时中间状态
|
||||
- **情景经验** - 记录先前运行中发生的事情
|
||||
- **语义知识** - 存储在任何单个情节之外都存在的抽象
|
||||
- **个性化记忆** - 跟踪关于特定用户、团队或环境的稳定信息
|
||||
|
||||
### 2. 技能系统：外部化程序专长
|
||||
|
||||
技能系统将程序、最佳实践和操作指导打包成可重用的人工制品，而不是依赖模型的权重在每次调用时重新生成特定任务的知识。
|
||||
|
||||
**核心转换**：从生成到组合——智能体从预先验证的组件组装行为，而不是从头即兴创作每个步骤。
|
||||
|
||||
技能的三个组成部分：
|
||||
- **操作程序** - 任务骨架：将复杂工作分解为步骤、阶段、依赖关系和停止条件
|
||||
- **决策启发式** - 管理分支处发生的情况
|
||||
- **规范性约束** - 程序被视为可接受的条件
|
||||
|
||||
### 3. 协议：外部化交互结构
|
||||
|
||||
协议定义了用于发现、调用、委托和权限管理的显式机器可读契约，而不是依赖临时提示级别的与工具、服务和其他智能体的协调。
|
||||
|
||||
**核心转换**：从临时到结构化——模糊、脆弱的通信变得可互操作、可治理的交换。
|
||||
|
||||
协议外部化的四个维度：
|
||||
- **调用语法** - 每个工具调用、API 请求或委托消息都需要一种格式
|
||||
- **生命周期语义** - 多步交互需要协调
|
||||
- **权限和信任边界** - 现实世界的智能体行为受到谁被授权的限制
|
||||
- **发现元数据** - 在智能体可以与工具或另一个智能体交互之前，它必须知道有哪些能力可用
|
||||
|
||||
## Harness 作为统一层
|
||||
|
||||
Harness 是承载所有三个维度并提供编排逻辑、约束、可观测性和反馈循环的工程层，使外部化认知在实践中连贯一致。
|
||||
|
||||
Harness 的六大分析维度：
|
||||
1. **智能体循环和控制流** - 智能体循环是 Harness 的时间骨干
|
||||
2. **沙箱和执行隔离** - 创建受控的执行边界
|
||||
3. **人工监督和审批门** - 在智能体循环中插入干预点
|
||||
4. **可观测性和结构化反馈** - 使智能体的内部轨迹对开发者、操作员和智能体本身可见
|
||||
5. **配置、权限和策略编码** - 编码不仅是智能体可以做什么，还有它在什么条件下被允许做什么
|
||||
6. **上下文预算管理** - 上下文窗口仍然是任何智能体系统中最稀缺的共享资源
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Memory-Systems|记忆系统]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
- [[Agent-Protocols|智能体协议]]
|
||||
|
||||
## 参考文档
|
||||
|
||||
- 原始论文：Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: "从权重到上下文到 Harness"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "历史演进"
|
||||
- "外部化"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 从权重到上下文到 Harness
|
||||
|
||||
LLM Agent 的近期历史可以被理解为从模型本身逐步向外移动的过程。能力首先被视为权重的属性，然后被视为提示和上下文窗口的属性，现在越来越被视为模型运行所在的更广泛基础设施的属性。
|
||||
|
||||
|
||||
|
||||
## 能力在权重中
|
||||
|
||||
Weights 层对应于现代 LLM 部署的最早浪潮，其中能力几乎完全与模型参数等同。
|
||||
|
||||
### 核心优势
|
||||
|
||||
- **快速推理**，无需外部查找
|
||||
- **紧凑部署**
|
||||
- **在许多任务中强大的泛化**，无需特定任务的管道
|
||||
|
||||
### 限制
|
||||
|
||||
- **知识、程序和策略与静态人工制品耦合太紧**
|
||||
- **更新单个事实需要重新训练、知识编辑或通过额外对齐层进行修补**
|
||||
- **审计为什么模型以某种方式表现很困难**，因为相关知识分布在数十亿个参数上
|
||||
- **个性化很尴尬** - 单一权重集被要求为数百万具有不同历史、偏好和约束的用户服务
|
||||
|
||||
> **参数知识的中心限制是难以选择性地更新、组合和治理。**
|
||||
|
||||
## 能力在上下文中
|
||||
|
||||
Context 层代表了注意力从模型修改转向输入设计的阶段。
|
||||
|
||||
### 关键发展
|
||||
|
||||
- **提示工程** 证明了模型行为可以在不接触权重的情况下大幅改变
|
||||
- **思维链 (Chain-of-Thought)** 使中间推理显式化
|
||||
- **ReAct** 在单个生成循环中将推理轨迹与工具行动交错
|
||||
- **思想树 (Tree of Thoughts)** 将思维链推广为对中间推理状态的刻意搜索
|
||||
- **Self-Refine** 引入了迭代自我批评
|
||||
- **检索增强生成 (RAG)** 通过在查询时动态将外部文档注入上下文，引入了更系统的外部化形式
|
||||
|
||||
### 优势
|
||||
|
||||
- **更灵活的 Agent 设计**
|
||||
- **开发者可以在运行时附加本地指令、领域知识、输出模式和检索证据**，无需任何梯度更新
|
||||
- **迭代提示和检索管道通常比微调更便宜、更快**
|
||||
- **模型可以保持冻结，而周围的提示模板、检索逻辑和工具规范快速演变**
|
||||
|
||||
### 表示转换
|
||||
|
||||
这可以通过 Norman 的认知人工制品概念来解释：
|
||||
|
||||
> 困难的回忆问题——"模型知道事实 X 吗？"——被转换为识别问题："鉴于事实 X 已放置在上下文中，模型可以使用它吗？"
|
||||
|
||||
### 约束
|
||||
|
||||
- **上下文窗口是有限的**，在规模上成本高昂，并且在过度加载边缘相关材料时经常有噪声
|
||||
- **长提示会降低性能**而不是提高它："中间丢失"现象表明模型在长输入中不均匀地参与
|
||||
- **上下文也是短暂的**：除非状态在其他地方显式外部化，否则每个新会话都以部分健忘症开始
|
||||
|
||||
## 能力通过基础设施
|
||||
|
||||
Harness 层代表了当前阶段，其中能力延伸超出提示管理进入持久基础设施。
|
||||
|
||||
### 早期表现
|
||||
|
||||
项目如 Auto-GPT 和 BabyAGI 用任务队列、持久记忆和网络访问将 LLM 包裹在循环中，表明即使是最小的 harness 也可以维持没有单个提示可以的行为。
|
||||
|
||||
### 更原则性的框架
|
||||
|
||||
- **AutoGen** 形式化了多智能体消息交换
|
||||
- **MetaGPT** 添加了基于角色的协作和显式程序
|
||||
- **CAMEL** 探索了用于任务分解的结构化对话
|
||||
- **Reflexion** 在剧集之间持续反馈
|
||||
|
||||
### 部署域中的模式
|
||||
|
||||
- **编码 Agent** 将模型嵌入开发 harness 中，带有文件、shell、版本控制、测试和可重用技能人工制品
|
||||
- **研究和企业 Agent** 添加检索、批准、浏览和长视野编排管道
|
||||
- **具身和工作流系统** 同样使控制流、环境访问和重用显式化
|
||||
|
||||
> **反复出现的模式是，可靠性问题越来越多地通过改变环境而不是仅通过提示来解决。**
|
||||
|
||||
## 外部化作为过渡逻辑
|
||||
|
||||
总之，从权重到上下文到 harness 的路径是 Norman 意义上的外部化故事：
|
||||
|
||||
- **可变知识**从权重移动到检索系统和运行时上下文，将回忆转换为识别
|
||||
- **可重用程序**从隐含习惯移动到显式技能，将即兴生成转换为结构化组合
|
||||
- **交互规则**从临时提示移动到协议，将模糊协调转换为受治理的契约
|
||||
- **运行时可靠性**移动到 harness 逻辑，其中约束、可观测性和反馈循环可以显式化
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
@@ -0,0 +1,319 @@
|
||||
---
|
||||
title: "Harness 工程完整指南"
|
||||
source: "https://www.nxcode.io/resources/news/harness-engineering-complete-guide-ai-agent-codex-2026"
|
||||
author: "NxCode Team"
|
||||
published: 2026-03-01
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- concepts
|
||||
- harness-engineering
|
||||
raw_sources:
|
||||
- path: raw/Harness Engineering The Complete Guide to Building Systems That Make AI Agents Actually Work (2026).md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# Harness 工程完整指南
|
||||
|
||||
如果说 2025 年是 AI 智能体证明它们可以编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。
|
||||
|
||||
OpenAI 的 Codex 团队刚刚构建了一个生产应用程序，**超过 100 万行代码**，其中**零行是由人工手写的**。工程师没有编写代码。他们设计了让 AI 可靠编写代码的系统。那个系统——约束、反馈循环、文档、linter 和生命周期管理——就是行业现在所称的 **Harness**。
|
||||
|
||||
**Harness 工程**是设计这些系统的新学科。它正在改变软件工程师的含义。
|
||||
|
||||
---
|
||||
|
||||
## 什么是 Harness 工程？
|
||||
|
||||
### 马的隐喻
|
||||
|
||||
"Harness" 一词来自马具——缰绳、马鞍、衔铁——用于将强大但不可预测的动物引导到正确方向的完整设备集。这个隐喻是有意的：
|
||||
|
||||
- **马**是 AI 模型——强大、快速，但它自己不知道去哪里
|
||||
- **Harness**是基础设施——约束、护栏、反馈循环，以富有成效地引导模型的力量
|
||||
- **骑手**是人类工程师——提供方向，而不是亲自奔跑
|
||||
|
||||
没有 Harness，AI 智能体就像开放领域中的纯种马。快速、令人印象深刻，但完全无法完成任何有用的事情。
|
||||
|
||||
### 正式定义
|
||||
|
||||
**Harness 工程**是设计和实现以下系统的学科：
|
||||
|
||||
1. **约束** AI 智能体可以做什么（架构边界、依赖规则）
|
||||
2. **告知** 智能体应该做什么（上下文工程、文档）
|
||||
3. **验证** 智能体正确完成了工作（测试、linting、CI 验证）
|
||||
4. **纠正** 智能体出错时的问题（反馈循环、自我修复机制）
|
||||
|
||||
Martin Fowler 将其描述为*"我们可以用来控制 AI 智能体的工具和实践"*——但这不仅仅是安全。一个好的 Harness 使智能体**更有能力**，而不仅仅是更受控制。
|
||||
|
||||
---
|
||||
|
||||
## 为什么 Harness 工程现在很重要
|
||||
|
||||
### 模型是商品，Harness 是护城河
|
||||
|
||||
AI 行业正在面对的令人不安的事实是：**底层模型的重要性不如其周围的系统。**
|
||||
|
||||
LangChain 明确证明了这一点。他们的编码智能体在 Terminal Bench 2.0 上从 **52.8% 提升到 66.5%**——从 **前 30 名跃升至前 5 名**——通过只改变 Harness，模型本身没有任何变化：
|
||||
|
||||
| 更改 | 他们做了什么 | 影响 |
|
||||
|------|-------------|------|
|
||||
| 自我验证循环 | 添加完成前检查清单中间件 | 在提交前捕获错误 |
|
||||
| 上下文工程 | 启动时映射目录结构 | 智能体从一开始就理解代码库 |
|
||||
| 循环检测 | 跟踪重复的文件编辑 | 防止"末日循环" |
|
||||
| 推理三明治 | 规划/验证使用高推理，实现使用中推理 | 在时间预算内提高质量 |
|
||||
|
||||
**相同的模型。不同的 Harness。显著更好的结果。**
|
||||
|
||||
### OpenAI 的 100 万行代码证明点
|
||||
|
||||
OpenAI 的实验是迄今为止最引人注目的证据：
|
||||
|
||||
- **5 个月**的开发
|
||||
- 最终产品中**超过 100 万行代码**
|
||||
- **零手动编写的行**——每一行都是由 Codex 智能体生成的
|
||||
- **以人类所需时间的约 1/10 构建**
|
||||
- 产品有**内部日常用户和外部 alpha 测试者**
|
||||
- 它**交付、部署、崩溃并得到修复**——所有这些都由 Harness 内的智能体完成
|
||||
|
||||
工程师的工作？设计 Harness。指定意图。提供反馈。不编写代码。
|
||||
|
||||
---
|
||||
|
||||
## Harness 工程的三大支柱
|
||||
|
||||
OpenAI 的框架将 Harness 工程组织为三个核心类别：
|
||||
|
||||
### 1. 上下文工程
|
||||
|
||||
上下文工程是关于确保智能体在正确的时间拥有正确的信息。
|
||||
|
||||
**静态上下文**：
|
||||
- 存储库本地文档（架构规范、API 契约、风格指南）
|
||||
- 编码项目特定规则的 `AGENTS.md` 或 `CLAUDE.md` 文件
|
||||
- 由 linter 验证的交叉链接设计文档
|
||||
|
||||
**动态上下文**：
|
||||
- 智能体可访问的可观测性数据（日志、指标、追踪）
|
||||
- 智能体启动时的目录结构映射
|
||||
- CI/CD 管道状态和测试结果
|
||||
|
||||
**关键规则**：从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**存储库必须是唯一的真实来源。**
|
||||
|
||||
### 2. 架构约束
|
||||
|
||||
这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好的代码"，不如**机械地强制执行好代码的样子。**
|
||||
|
||||
**依赖分层**：
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
|
||||
每一层只能从其左侧的层导入。这不是建议——它由结构测试和 CI 验证强制执行。
|
||||
|
||||
**约束强制执行工具**：
|
||||
- **确定性 linter**——自动标记违规的自定义规则
|
||||
- **基于 LLM 的审计器**——审查其他智能体代码的架构合规性的智能体
|
||||
- **结构测试**——像 ArchUnit，但用于 AI 生成的代码
|
||||
- **预提交钩子**——任何代码提交前的自动检查
|
||||
|
||||
**为什么约束可以改善输出**：矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
|
||||
### 3. 熵管理（"垃圾收集"）
|
||||
|
||||
这是最被低估的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定发散、死代码积累。
|
||||
|
||||
Harness 工程通过**定期清理智能体**来解决这个问题：
|
||||
- **文档一致性智能体**——验证文档与当前代码匹配
|
||||
- **约束违规扫描器**——找到通过早期检查的代码
|
||||
- **模式强制执行智能体**——识别并修复与既定模式的偏差
|
||||
- **依赖审计器**——跟踪并解决循环或不必要的依赖
|
||||
|
||||
这些智能体按计划运行——每天、每周或由特定事件触发——保持代码库对人类审查者和未来 AI 智能体都健康。
|
||||
|
||||
---
|
||||
|
||||
## Harness 工程实践：团队实际如何做
|
||||
|
||||
### OpenAI 方法：零人工代码
|
||||
|
||||
OpenAI 的 Harness 工程团队结构：
|
||||
|
||||
| 角色 | 传统 | Harness 工程 |
|
||||
|------|------|-------------|
|
||||
| 编写代码 | 主要工作 | 从不 |
|
||||
| 设计架构 | 工作的一部分 | 主要工作 |
|
||||
| 编写文档 | 事后考虑 | 关键基础设施 |
|
||||
| 审查 PR | 代码审查 | 审查智能体输出 + Harness 有效性 |
|
||||
| 调试 | 阅读代码 | 分析智能体行为模式 |
|
||||
| 测试 | 编写测试 | 设计智能体执行的测试策略 |
|
||||
|
||||
### Stripe 方法：规模化的 Minions
|
||||
|
||||
Stripe 的内部编码智能体，称为 **Minions**，现在每周产生**超过 1,000 个合并的拉取请求**：
|
||||
|
||||
1. 开发者在 Slack 中发布任务
|
||||
2. Minion 编写代码
|
||||
3. Minion 通过 CI
|
||||
4. Minion 打开 PR
|
||||
5. 人类审查并合并
|
||||
|
||||
第 1 步和第 5 步之间没有开发者交互。Harness 处理一切——测试执行、CI 验证、风格合规和文档更新。
|
||||
|
||||
### LangChain 方法：中间件优先
|
||||
|
||||
LangChain 将他们的 Harness 构建为可组合的中间件层：
|
||||
|
||||
```
|
||||
Agent Request
|
||||
→ LocalContextMiddleware (映射代码库)
|
||||
→ LoopDetectionMiddleware (防止重复)
|
||||
→ ReasoningSandwichMiddleware (优化计算)
|
||||
→ PreCompletionChecklistMiddleware (强制执行验证)
|
||||
→ Agent Response
|
||||
```
|
||||
|
||||
每个中间件层都添加特定功能，而不修改核心智能体逻辑。这种模块化方法使 Harness 可测试且可演进。
|
||||
|
||||
---
|
||||
|
||||
## 构建你的第一个 Harness：实用框架
|
||||
|
||||
### 级别 1：基础 Harness（单个开发者）
|
||||
|
||||
如果你正在使用 Claude Code、Cursor 或 Codex 进行个人项目：
|
||||
|
||||
**需要设置什么**：
|
||||
- 带有项目约定的 `CLAUDE.md` 或 `.cursorrules` 文件
|
||||
- 用于 linting 和格式化的预提交钩子
|
||||
- 智能体可以运行以自我验证的测试套件
|
||||
- 具有一致命名的清晰目录结构
|
||||
|
||||
**设置时间**：1-2 小时 **影响**：防止最常见的智能体错误
|
||||
|
||||
### 级别 2：团队 Harness（小团队）
|
||||
|
||||
对于 3-10 个共享代码库的开发者团队：
|
||||
|
||||
**添加到级别 1**：
|
||||
- 带有团队范围约定的 `AGENTS.md`
|
||||
- 由 CI 强制执行的架构约束
|
||||
- 常见任务的共享提示模板
|
||||
- 由 linter 验证的文档即代码
|
||||
- 专门针对智能体生成 PR 的代码审查检查清单
|
||||
|
||||
**设置时间**：1-2 天 **影响**：跨团队一致的智能体行为
|
||||
|
||||
### 级别 3：生产 Harness（工程组织）
|
||||
|
||||
对于运行数十个并发智能体的组织：
|
||||
|
||||
**添加到级别 2**：
|
||||
- 自定义中间件层（循环检测、推理优化）
|
||||
- 可观测性集成（智能体读取日志和指标）
|
||||
- 计划运行的熵管理智能体
|
||||
- Harness 版本控制和 A/B 测试
|
||||
- 智能体性能监控仪表板
|
||||
- 智能体卡住时的升级策略
|
||||
|
||||
**设置时间**：1-2 周 **影响**：智能体作为自主贡献者运作
|
||||
|
||||
---
|
||||
|
||||
## 常见的 Harness 工程错误
|
||||
|
||||
### 1. 过度工程化控制流
|
||||
|
||||
> *"如果你过度工程化控制流，下一次模型更新会破坏你的系统。"*
|
||||
|
||||
模型改进迅速。2024 年需要复杂管道的能力现在由单个上下文窗口提示处理。构建你的 Harness 以**可剥离**——当模型变得足够智能不需要时，你应该能够删除"智能"逻辑。
|
||||
|
||||
### 2. 将 Harness 视为静态的
|
||||
|
||||
Harness 需要与模型一起演进。当新模型版本改进推理时，你的推理优化中间件可能会适得其反。每次重大模型更新时审查和更新 Harness 组件。
|
||||
|
||||
### 3. 忽略文档层
|
||||
|
||||
最有影响力的 Harness 改进通常是最简单的：**更好的文档**。如果你的 `AGENTS.md` 含糊不清，你的智能体输出也会含糊不清。投资于精确、机器可读的文档，作为智能体的基础事实。
|
||||
|
||||
### 4. 没有反馈循环
|
||||
|
||||
没有反馈的 Harness 是一个笼子，而不是指南。智能体需要知道它何时成功何时失败。内置：
|
||||
- 任务完成前的自我验证步骤
|
||||
- 作为智能体工作流一部分的测试执行
|
||||
- 按任务类型划分的智能体成功率指标
|
||||
|
||||
### 5. 只有人类的文档
|
||||
|
||||
如果你的架构决策存在于人们的头脑中或智能体无法访问的 Confluence 页面中，Harness 就有差距。**智能体需要的一切都必须在存储库中。**
|
||||
|
||||
---
|
||||
|
||||
## Harness 工程与相关概念
|
||||
|
||||
| 概念 | 范围 | 焦点 |
|
||||
|------|------|------|
|
||||
| **提示工程** | 单次交互 | 制作有效的提示 |
|
||||
| **上下文工程** | 模型上下文窗口 | 模型看到什么信息 |
|
||||
| **Harness 工程** | 整个智能体系统 | 环境、约束、反馈、生命周期 |
|
||||
| **智能体工程** | 智能体架构 | 内部智能体设计和路由 |
|
||||
| **平台工程** | 基础设施 | 部署、扩展、运营 |
|
||||
|
||||
Harness 工程**包括**上下文工程并借鉴提示工程，但它在更高层次上运作——它是关于使智能体可靠的完整系统，而不仅仅是单次交互的输入。
|
||||
|
||||
---
|
||||
|
||||
## 这对软件工程师意味着什么
|
||||
|
||||
### 工作正在改变
|
||||
|
||||
Harness 工程代表了软件工程师工作的真正演变：
|
||||
|
||||
| 之前 | 之后 |
|
||||
|------|------|
|
||||
| 编写代码 | 设计 AI 编写代码的环境 |
|
||||
| 调试代码 | 调试智能体行为 |
|
||||
| 审查代码 | 审查智能体输出 + Harness 有效性 |
|
||||
| 编写测试 | 设计测试策略 |
|
||||
| 维护文档 | 构建文档作为机器可读基础设施 |
|
||||
|
||||
这并不意味着工程师变得不那么技术。如果说有什么不同的话，Harness 工程需要**更深**的架构思考——你正在设计必须在没有你持续干预的情况下工作的系统。
|
||||
|
||||
### 重要的技能
|
||||
|
||||
基于在 NxCode 构建 AI 驱动产品的所见：
|
||||
|
||||
1. **系统思维**——理解约束、反馈循环和文档如何交互
|
||||
2. **架构设计**——定义可强制执行且富有成效的边界
|
||||
3. **规范编写**——足够精确地表达意图，让智能体可以执行
|
||||
4. **可观测性**——构建揭示智能体行为模式的监控
|
||||
5. **迭代速度**——快速测试和完善 Harness 配置
|
||||
|
||||
### 实践经验：什么有效
|
||||
|
||||
使用多个智能体系统（Claude Code、Codex、Cursor）构建 AI 驱动的 Web 应用程序。产生最大差异的模式：
|
||||
|
||||
- **存储库优先文档**：每个架构决策、命名约定和部署过程都在 repo 中。没有任何东西存在于 Slack 或 Google Docs 中。
|
||||
- **增量约束构建**：从基本 linting 开始，随着模式出现添加架构约束，不要尝试预先设计完美的 Harness。
|
||||
- **智能体特定审查检查清单**：AI 生成的代码与人类代码有不同的失败模式。审查过程考虑常见的智能体模式（过度抽象、不必要的错误处理、文档漂移）。
|
||||
- **多提供商 Harness 设计**：Harness 适用于 Claude、GPT 和 Gemini 模型。提供商无关设计意味着可以切换模型而无需重建整个系统。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Harness 工程是新学科**——设计使 AI 智能体可靠的系统——约束、反馈循环、文档和生命周期管理
|
||||
2. **模型是商品；Harness 是护城河**——LangChain 通过只改变 Harness 从基准前 30 名跃升至前 5 名
|
||||
3. **OpenAI 用零人工代码构建了 100 万+行**——证明 Harness 工程在生产规模上有效
|
||||
4. **三大支柱**：上下文工程、架构约束和熵管理
|
||||
5. **简单开始**：一个好的 `AGENTS.md` 和预提交钩子比复杂中间件更有影响力
|
||||
6. **工程师的工作正在演变**——从编写代码到设计 AI 编写代码的环境
|
||||
7. **构建可剥离的 Harness**——当模型改进时，过度工程化会破裂；保持适应性
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
- [[LangChain-Harness-Engineering|LangChain Harness 工程实践]]
|
||||
- [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
title: "Harness 工程：最初的思考"
|
||||
source: "https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html"
|
||||
author: "Birgitta Böckeler"
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- concepts
|
||||
- harness-engineering
|
||||
raw_sources:
|
||||
- path: raw/Harness Engineering - first thoughts.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# Harness 工程：最初的思考
|
||||
|
||||
本文是 Martin Fowler 团队关于 Harness 工程的早期思考备忘录。在撰写本文后，Birgitta Böckeler 进一步分析了这个主题，并撰写了一篇[更深入的文章描述 Harness 工程](https://martinfowler.com/articles/harness-engineering.html)。
|
||||
|
||||
---
|
||||
|
||||
## 背景
|
||||
|
||||
阅读 OpenAI 最近关于["Harness 工程"的文章](https://openai.com/index/harness-engineering/)非常有趣。这篇文章描述了一个团队如何使用"完全没有手动输入的代码"作为强制函数，来构建一个用于用 AI 智能体维护大型应用程序的 Harness。经过 5 个月，他们构建了一个现在超过 100 万行代码的真实产品。
|
||||
|
||||
这篇文章的标题是"Harness 工程：在智能体优先的世界中利用 Codex"，但在正文中只提到了一次"harness"。也许这个术语是受到 [Mitchell Hashimoto](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) 最近博客文章的启发。无论如何，我喜欢"harness"这个词来描述我们可以用来控制 AI 智能体的工具和实践。
|
||||
|
||||
---
|
||||
|
||||
## OpenAI 团队的 Harness 三大类别
|
||||
|
||||
OpenAI 团队的 Harness 组件混合了确定性和基于 LLM 的方法，分为 3 个类别（基于我的解释）：
|
||||
|
||||
### 1. 上下文工程
|
||||
- 代码库中持续增强的知识库
|
||||
- 智能体访问动态上下文，如可观测性数据和浏览器导航
|
||||
|
||||
### 2. 架构约束
|
||||
- 不仅由基于 LLM 的智能体监控，还包括确定性的自定义 linter 和结构测试
|
||||
|
||||
### 3. "垃圾收集"
|
||||
- 定期运行的智能体，用于查找文档中的不一致性或架构约束的违规行为
|
||||
- 对抗熵和衰减
|
||||
|
||||
他们还强调了这是多么迭代："当智能体遇到困难时，我们将其视为一个信号：识别缺少什么——工具、护栏、文档——并将其反馈回存储库，始终通过让 Codex 自己编写修复。"
|
||||
|
||||
所有描述的措施都专注于提高长期内部质量和可维护性。我在这篇文章中缺少的是对功能和行为的验证。
|
||||
|
||||
---
|
||||
|
||||
## 思考与假设
|
||||
|
||||
撇开这个差距不谈，假设我们可以相信 OpenAI 对这一成功的描述（关于作者和团队，OpenAI 确实有让我们相信 AI 可维护代码的既得利益）——以下是我对文章中*实际*内容的思考。
|
||||
|
||||
### Harness——未来的服务模板？
|
||||
|
||||
大多数组织只有两三个主要技术栈——不是每个应用程序都是自己的雪花。这篇文章让我想象一个未来，团队从一组用于常见应用拓扑的 Harness 中挑选来开始。这唤起了今天的服务模板，它们帮助团队在"黄金路径"上实例化新服务。Harness——带有自定义 linter、结构测试、基本上下文和知识文档以及额外的上下文提供者——会成为新的服务模板吗？团队会将它们用作起点，然后随着时间的推移根据其应用程序的具体情况塑造它们吗？
|
||||
|
||||
使用服务模板，团队随着获得经验而贡献回来，然后其他团队经常在合并更新时遇到困难。我们会看到 Harness 类似的分叉和同步挑战吗？
|
||||
|
||||
### 运行时必须受到约束以获得更多 AI 自主权？
|
||||
|
||||
很多早期和当前的 AI 编码炒作假设 LLM 会给我们目标运行时的无限灵活性。生成任何语言、任何模式，没有约束——LLM 会弄清楚的。但对于我们可以信任的大规模、可维护的 AI 生成代码，必须有所放弃。
|
||||
|
||||
描述的 Harness 表明，增加信任和可靠性需要约束解决方案空间：特定的架构模式、强制执行的边界、标准化的结构。这意味着放弃一些"生成任何东西"的灵活性，以换取充满技术细节的提示、规则和 Harness。
|
||||
|
||||
### 收敛到有限数量的技术栈和拓扑？
|
||||
|
||||
随着编码变得越来越少关于输入代码，而越来越多关于指导其生成，AI 可能会推动我们走向更少的技术栈。框架和 SDK 的可用性仍然很重要——我们反复看到，对人类有益的对 AI 也有益。但开发者的品味在那个细节级别上就不那么重要了。接口中的小低效和特质不会那么烦人，因为我们不会直接处理它们。我们可能会选择有好的 Harness 可用的栈，并优先考虑"AI 友好性"。
|
||||
|
||||
这可能不仅适用于技术栈，还适用于代码库结构和拓扑。我们可能会默认使用更容易用 AI 维护的结构，因为它们更容易被 Harness。OpenAI 团队讨论了架构刚性和强制执行规则。我可以看到的主要焦点领域是保持数据结构稳定以及定义和强制执行模块边界。听起来合理——但没有具体示例，我仍然很难想象"我们要求 Codex 在边界解析数据形状"在他们的 Harness 中实际上是什么样子。
|
||||
|
||||
但如果我们能广泛弄清楚如何利用代码库设计模式的 Harness，这些拓扑会成为新的抽象层，而不是像那么多 AI 爱好者希望的自然语言本身吗？
|
||||
|
||||
### 两个未来世界：AI 前 vs AI 后应用维护？
|
||||
|
||||
假设我们开发了好的 Harness 技术，将 AI 自主权调到 9 并增加我们对结果的信心。哪些技术可以应用于现有应用程序，哪些只适用于从头开始构建并考虑 Harness 的应用程序？
|
||||
|
||||
对于较旧的代码库，我们需要考虑改造 Harness 是否值得付出努力。AI 可以帮助我们更快地做到这一点，但这些应用程序通常如此非标准化且充满熵，可能不值得。这让我想到在一个从未有过静态代码分析工具的代码库上运行它，然后淹没在警报中。
|
||||
|
||||
### 你今天的 Harness 是什么？
|
||||
|
||||
这个团队在他们的 Harness 上工作了 5 个月，这表明这不是你可以为快速结果而跳入的事情。但值得反思你今天的 Harness 是什么。你有预提交钩子吗？里面有什么？你对自定义 linter 有想法吗？你想对你的代码库施加什么架构约束？你尝试过像 ArchUnit 这样的结构测试框架吗？
|
||||
|
||||
---
|
||||
|
||||
## 最后的思考
|
||||
|
||||
不出所料，他们描述的听起来比仅仅生成和维护一堆 Markdown 规则文件要多得多的工作。他们为 Harness 的确定性部分构建了广泛的工具。他们的上下文工程不仅涉及策划知识库，还涉及重要的设计工作——代码设计本身就是上下文的巨大组成部分。
|
||||
|
||||
OpenAI 团队说："我们最困难的挑战现在集中在设计环境、反馈循环和控制系统上。"这让我想起了 [Chad Fowler 最近关于"重新定位严谨性"的文章](https://aicoding.leaflet.pub/3mbrvhyye4k2e)。听到关于那个严谨性可能去向的具体想法和经验，而不仅仅是希望"更好的模型"会神奇地解决可维护性问题，这令人耳目一新。
|
||||
|
||||
最后，就这一次，我喜欢这个领域的一个术语。虽然它只有 2 周大——我可能可以屏住呼吸，直到有人把他们的单提示、基于 LLM 的代码审查智能体称为 Harness……
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
@@ -0,0 +1,163 @@
|
||||
---
|
||||
title: "面向编码智能体用户的 Harness 工程"
|
||||
source: "https://martinfowler.com/articles/harness-engineering.html"
|
||||
author: "Birgitta Böckeler"
|
||||
published: 2026-04-02
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- concepts
|
||||
- harness-engineering
|
||||
raw_sources:
|
||||
- path: raw/Harness engineering for coding agent users.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# 面向编码智能体用户的 Harness 工程
|
||||
|
||||
本文由 Martin Fowler 团队的 Birgitta Böckeler 撰写，提供了一个在编码智能体语境下构建信任的思维模型——通过前馈指南、反馈传感器和迭代式 Harness 工程。
|
||||
|
||||
## 核心定义
|
||||
|
||||
**Harness** 这个术语已经成为 AI 智能体中除模型本身外一切的简写——[智能体 = 模型 + Harness](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)。这是一个非常宽泛的定义，因此值得为常见的智能体类别缩小范围。
|
||||
|
||||
在**编码智能体**的语境下，Harness 的一部分已经内置（例如通过系统提示词、选择的代码检索机制，甚至是[复杂的编排系统](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)）。但编码智能体也为用户提供了许多功能来构建专门针对用例和系统的**外层 Harness**。
|
||||
|
||||
|
||||
|
||||
**图 1**："Harness" 一词的含义取决于边界上下文。三个同心圆：模型在核心（最终被 harness 的事物），然后是编码智能体的构建者 harness，再外面是编码智能体的用户 harness。
|
||||
|
||||
---
|
||||
|
||||
## Harness 的双重目标
|
||||
|
||||
一个构建良好的外层 Harness 服务于两个目标：
|
||||
|
||||
1. **提高智能体第一次就做对的概率**
|
||||
2. **提供一个反馈循环，在问题到达人眼之前自我纠正尽可能多的问题**
|
||||
|
||||
最终，它应该减少审查工作并提高系统质量，同时还能减少浪费的 token。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 计算型 vs 推理型
|
||||
|
||||
指南和传感器有两种执行类型：
|
||||
|
||||
| 类型 | 描述 | 示例 | 速度 | 可靠性 |
|
||||
|------|------|------|------|--------|
|
||||
| **计算型（Computational）** | 确定性且快速，由 CPU 运行 | 测试、lint、类型检查器、结构分析 | 毫秒到秒 | 可靠 |
|
||||
| **推理型（Inferential）** | 语义分析、AI 代码审查、"LLM 作为法官" | 语义分析、AI 代码审查 | 更慢更昂贵 | 更不确定 |
|
||||
|
||||
**计算型指南**通过确定性工具提高良好结果的概率。**计算型传感器**足够便宜和快速，可以在每次更改时与智能体一起运行。**推理型控制**当然更昂贵且更不确定，但允许我们既提供丰富的指导，又添加额外的语义判断。尽管具有不确定性，当使用强大的模型或适合手头任务的模型时，推理型传感器尤其可以增加我们的信任。
|
||||
|
||||
---
|
||||
|
||||
## 引导循环
|
||||
|
||||
人类在这其中的工作是通过迭代 Harness 来**引导**智能体。每当问题多次发生时，应该改进前馈和反馈控制，以使问题将来发生的可能性降低，甚至完全防止它。
|
||||
|
||||
在引导循环中，当然也可以使用 AI 来改进 Harness。编码智能体现在使构建更多自定义控制和更多自定义静态分析变得便宜得多。智能体可以帮助编写结构测试、从观察到的模式生成规则草案、搭建自定义 linter，或从代码库考古中创建操作指南。
|
||||
|
||||
---
|
||||
|
||||
## 时机：保持质量向左
|
||||
|
||||
持续集成的团队一直面临着根据成本、速度和关键程度在开发时间线上分布测试、检查和人工审查的挑战。当渴望持续交付时，理想情况下甚至希望每个提交状态都可部署。你希望检查尽可能靠近生产路径的左侧，因为越早发现问题，修复成本就越低。反馈传感器，包括新的推理型传感器，需要相应地分布在整个生命周期中。
|
||||
|
||||
**变更生命周期中的前馈和反馈**：
|
||||
- 什么是足够快的，甚至应该在集成之前运行，甚至在创建提交之前？（例如 linter、快速测试套件、基本代码审查智能体）
|
||||
- 什么更昂贵，因此只应在集成后在管道中运行，除了重复快速控制之外？（例如突变测试、可以考虑更大图景的更广泛代码审查）
|
||||
|
||||
**持续漂移和健康传感器**：
|
||||
- 什么类型的漂移会逐渐累积，应该通过在变更生命周期之外持续运行的传感器来监控？（例如死代码检测、测试覆盖质量分析、依赖扫描器）
|
||||
- 智能体可以监控什么运行时反馈？（例如让它们查找恶化的 SLO 以提出改进建议，或 AI 法官持续采样响应质量并标记日志异常）
|
||||
|
||||
---
|
||||
|
||||
## 监管类别
|
||||
|
||||
智能体 Harness 就像一个[控制论](https://en.wikipedia.org/wiki/Cybernetics)调速器，结合前馈和反馈来调节代码库朝其期望状态发展。区分期望状态的多个维度是有用的，按 Harness 应该监管的内容分类。区分这些类别有帮助，因为 Harness 能力和复杂性在它们之间变化，限定这个词为我们提供了更精确的语言，否则这个术语会非常通用。
|
||||
|
||||
### 可维护性 Harness（Maintainability harness）
|
||||
|
||||
本文中给出的几乎所有示例都是关于监管内部代码质量和可维护性的。这目前是最容易的 Harness 类型，因为我们有很多可以用于此的预先存在的工具。
|
||||
|
||||
**计算型传感器**可靠地捕获结构性内容：重复代码、循环复杂度、缺失的测试覆盖、架构漂移、风格违规。这些便宜、经过验证且确定。
|
||||
|
||||
**LLM 可以部分解决需要语义判断的问题**——语义重复代码、冗余测试、暴力修复、过度工程化的解决方案——但昂贵且概率性。不是在每个提交上。
|
||||
|
||||
**两者都不能可靠地捕获一些更高影响的问题**：问题的误诊、过度工程化和不必要的功能、误解的指令。它们有时会捕获，但不够可靠以减少监督。如果人类首先没有清楚地指定他们想要什么，正确性就不在任何传感器的范围内。
|
||||
|
||||
### 架构适用性 Harness（Architecture fitness harness）
|
||||
|
||||
这组指南和传感器定义和检查应用程序的架构特征。基本上：[适用性函数](https://www.thoughtworks.com/en-de/radar/techniques/architectural-fitness-function)。
|
||||
|
||||
**示例**：
|
||||
- 前馈我们性能要求的技能，以及反馈给智能体它是改进还是降低了性能的性能测试
|
||||
- 描述更好可观测性编码约定的技能（如日志标准），以及要求智能体反思它可用的日志质量的调试指令
|
||||
|
||||
### 行为 Harness（Behaviour harness）
|
||||
|
||||
这是房间里的大象——我们如何引导和感知应用程序是否按照我们需要的方式功能运行？目前，看到大多数给编码智能体高度自主权的人都这样做：
|
||||
|
||||
- **前馈**：功能规范（详细程度不一，从简短提示到多文件描述）
|
||||
- **反馈**：检查 AI 生成的测试套件是否通过，具有合理的高覆盖，有些人甚至可能用突变测试监控其质量。然后将其与手动测试结合。
|
||||
|
||||
这种方法对 AI 生成的测试寄予了很大信任，这还不够好。一些同事在[批准夹具](https://lexler.github.io/augmented-coding-patterns/patterns/approved-fixtures/)模式上看到了良好结果，但它在某些领域比其他领域更容易应用。他们有选择地在适合的地方使用它，这不是测试质量问题的全面答案。
|
||||
|
||||
因此总的来说，我们仍有很多工作要做，以找出功能行为的良好 Harness，增加我们的信心足以减少监督和手动测试。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Harness 能力
|
||||
|
||||
并非每个代码库都同样适合 Harnessing。用强类型语言编写的代码库自然有类型检查作为传感器；可明确定义的模块边界提供架构约束规则；像 Spring 这样的框架抽象掉了智能体甚至不必担心的细节，因此隐式地提高了智能体成功的机会。没有这些属性，这些控制就无法构建。
|
||||
|
||||
这在绿地与遗留项目中表现不同。绿地团队可以从第一天就内置 Harness 能力——技术决策和架构选择决定了代码库的可治理程度。遗留团队，尤其是那些积累了大量技术债务的应用程序，面临更难的问题：Harness 最需要的地方也是最难构建的地方。
|
||||
|
||||
---
|
||||
|
||||
## Harness 模板
|
||||
|
||||
大多数企业都有一些常见的服务拓扑，覆盖了他们需要的 80%——通过 API 暴露数据的业务服务；事件处理服务；数据仪表板。在许多成熟的工程组织中，这些拓扑已经在服务模板中编码。这些将来可能会演变成 Harness 模板：一组指南和传感器的捆绑包，将编码智能体拴在拓扑的结构、约定和技术栈上。团队可能会部分基于已经有哪些可用的 Harness 来选择技术栈和结构。
|
||||
|
||||
|
||||
|
||||
我们当然会面临与服务模板类似的挑战。一旦团队实例化它们，它们就开始与上游改进不同步。Harness 模板将面临相同的版本控制和贡献问题，对于非确定性且更难测试的指南和传感器可能甚至更糟。
|
||||
|
||||
---
|
||||
|
||||
## 人类的角色
|
||||
|
||||
作为人类开发者，我们将我们的技能和经验作为隐式 Harness 带到每个代码库。我们吸收了约定和良好实践，我们感受到了复杂性的认知痛苦，我们知道我们的名字在提交上。我们还携带着组织一致性——意识到团队正在努力实现什么，哪些技术债务因业务原因被容忍，以及在这个特定上下文中"好"是什么样子。我们以小步骤和我们人类的速度前进，这为该经验被触发和应用创造了思考空间。
|
||||
|
||||
编码智能体没有这一切：没有社会责任感，对 300 行函数没有美学厌恶，没有"我们这里不那样做"的直觉，也没有组织记忆。它不知道哪个约定是承载负载的，哪个只是习惯，或者技术上正确的解决方案是否适合团队正在努力做的事情。
|
||||
|
||||
Harness 是尝试外化并明确人类开发者经验带来的东西，但它只能走这么远。构建一个连贯的指南和传感器系统以及自我纠正循环是昂贵的，因此我们必须以明确的目标优先考虑：一个好的 Harness 不一定旨在完全消除人类输入，而是将其引导到我们的输入最重要的地方。
|
||||
|
||||
---
|
||||
|
||||
## 起点——和开放问题
|
||||
|
||||
这里阐述的思维模型描述了已经在实践中发生的技术，并帮助框架讨论我们仍需要弄清楚的内容。其目标是将对话提升到功能级别之上——从技能和 MCP 服务器到我们如何战略性地设计一个控制系统，让我们对智能体产生的内容真正有信心。
|
||||
|
||||
以下是当前话语中与 Harness 相关的一些示例：
|
||||
- [OpenAI 团队记录了他们的 Harness 是什么样子](https://openai.com/index/harness-engineering/)：由自定义 linter 和结构测试强制执行的分层架构，以及定期的"垃圾收集"来扫描漂移并让智能体建议修复。他们的结论："我们最困难的挑战现在集中在设计环境、反馈循环和控制系统上。"
|
||||
- [Stripe 关于他们的 minions 的文章](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents)描述了诸如基于启发式运行相关 linter 的预推送钩子之类的事情，他们强调了"向左反馈"对他们有多重要，他们的"蓝图"展示了他们如何将反馈传感器集成到智能体工作流中。
|
||||
- 突变和结构测试是计算型反馈传感器的示例，它们在过去未被充分利用，但现在正在复兴。
|
||||
- 开发者之间关于在编码智能体中集成 LSP 和代码智能的讨论越来越多，这是计算型前馈指南的示例。
|
||||
- 听到 Thoughtworks 团队关于使用计算型和推理型传感器解决架构漂移的故事，例如通过智能体和自定义 linter 的混合提高 API 质量，或通过"清洁大军"提高代码质量。
|
||||
|
||||
还有很多需要弄清楚的，不仅仅是已经提到的行为 Harness。我们如何保持 Harness 连贯随着它的增长，指南和传感器同步，不相互矛盾？当指令和反馈信号指向不同方向时，我们能在多大程度上信任智能体做出明智的权衡？如果传感器从不触发，这是高质量的标志还是检测机制不足？我们需要一种类似于测试的代码覆盖和突变测试的方法来评估 Harness 覆盖和质量。前馈和反馈控制目前分散在交付步骤中，工具有真正的潜力来帮助配置、同步和推理它们作为一个系统。构建这个外层 Harness 正在成为一个持续的工程实践，而不是一次性配置。
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Mitchellh-AI-Adoption-Journey|Mitchell Hashimoto 的 AI 采用之旅]]
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
@@ -1,137 +1,146 @@
|
||||
---
|
||||
title: Harness 工程
|
||||
tags: [核心概念, Harness, 架构]
|
||||
source: [OpenAI, Anthropic, Martin Fowler, LangChain, NxCode]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
title: "Harness 工程"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "Harness工程"
|
||||
- "智能体架构"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# Harness 工程
|
||||
|
||||
**Harness 工程**（Harness Engineering）是设计和实现使 AI 智能体可靠工作的系统的新学科。如果说 2025 年是 AI 智能体验证它们能够编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。
|
||||
**Harness 工程**是构建外部化 Agent 运行时环境的综合学科。它将记忆、技能和协议这三个外部化模块统一成一个连贯的认知环境。
|
||||
|
||||
## 核心定义
|
||||
## 什么是 Harness？
|
||||
|
||||
### 什么是 Harness？
|
||||
Harness 是将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。
|
||||
|
||||
术语 "Harness" 来源于马具——缰绳、马鞍、马嚼子——用于引导强大但不可预测的动物朝正确方向前进的全套设备。这个比喻是有意为之的：
|
||||
> **核心洞见**：Harness 不仅仅是实现便利性，它是设计的认知环境，外部化模块在其中共同生效。
|
||||
|
||||
- **马**是 AI 模型——强大、快速，但自己不知道要去哪里
|
||||
- **Harness**是基础设施——约束、护栏、反馈循环，用于高效地引导模型的能力
|
||||
- **骑手**是人类工程师——提供方向，而不是亲自奔跑
|
||||
### Harness 的功能组成
|
||||
|
||||
没有 Harness，AI 智能体就像开放田野里的纯种马。快速、令人印象深刻，但对于完成任何事情来说完全无用。
|
||||
Harness 包含使这种耦合成为可能的外部系统：
|
||||
- 持久记忆和项目级上下文
|
||||
- 可重用技能和可执行例程
|
||||
- 用于与工具和服务进行确定性交互的协议化接口
|
||||
- 更广泛的运行时基础设施
|
||||
|
||||
### Harness 工程的正式定义
|
||||
## Harness 的六大分析维度
|
||||
|
||||
**Harness 工程**是设计和实现以下系统的学科：
|
||||
|
||||
|
||||
1. **约束** AI 智能体可以做什么（架构边界、依赖规则）
|
||||
2. **告知** 智能体应该做什么（上下文工程、文档）
|
||||
3. **验证** 智能体正确执行了（测试、linting、CI 验证）
|
||||
4. **纠正** 智能体出错时（反馈循环、自我修复机制）
|
||||
### 1. 智能体循环和控制流
|
||||
|
||||
Martin Fowler 将其描述为"我们可以用来控制 AI 智能体的工具和实践"——但它不仅仅是安全。一个好的 Harness 使智能体**更有能力**，而不仅仅是更受控制。
|
||||
智能体循环是 Harness 的时间骨干。最简单的形式是实现感知-检索-计划-行动-观察周期。
|
||||
|
||||
## 为什么 Harness 工程现在如此重要
|
||||
**关键控制机制**：
|
||||
- 最大步数限制
|
||||
- 递归深度边界
|
||||
- 每步成本上限
|
||||
- 超时约束
|
||||
|
||||
### 模型是商品，Harness 是护城河
|
||||
这些控制定义了模型推理展开的操作 envelope。
|
||||
|
||||
AI 行业正面临一个令人不安的事实：**底层模型的重要性不如围绕它的系统。**
|
||||
### 2. 沙箱和执行隔离
|
||||
|
||||
LangChain 明确证明了这一点。他们的编码智能体在 Terminal Bench 2.0 上从 **52.8% 提升到 66.5%**——从 **Top 30 跃升至 Top 5**——对模型没有做任何改变。他们只改变了 Harness：
|
||||
每当 Agent 对世界采取行动时，Harness 必须决定暴露多少环境以及如何包含意外的副作用。
|
||||
|
||||
| 改变 | 他们做了什么 | 影响 |
|
||||
|------|-------------|------|
|
||||
| 自我验证循环 | 添加完成前检查清单中间件 | 在提交前捕获错误 |
|
||||
| 上下文工程 | 启动时映射目录结构 | 智能体从一开始就理解代码库 |
|
||||
| 循环检测 | 跟踪重复的文件编辑 | 防止"末日循环" |
|
||||
| 推理三明治 | 规划/验证使用高推理，实现使用中等推理 | 在时间预算内获得更好的质量 |
|
||||
**隔离粒度**：
|
||||
- **云沙箱** - 每个任务在专用云沙箱中运行，带有自己的文件系统快照、网络限制和资源配额
|
||||
- **分级权限模式** - 暴露从完全自主执行到每个工具调用都需要强制用户批准的分级权限模式
|
||||
|
||||
**相同的模型。不同的 Harness。显著更好的结果。**
|
||||
**沙箱的双重作用**：
|
||||
1. 安全围栏 - 限制危险操作
|
||||
2. 认知边界 - 通过移除不相关状态简化 Agent 的操作环境
|
||||
|
||||
### OpenAI 的 100 万行代码证明点
|
||||
### 3. 人工监督和审批门
|
||||
|
||||
OpenAI 的实验是迄今为止最令人信服的证据：
|
||||
完全自主很少适合部署的 Agent。大多数生产系统在 Agent 循环中插入干预点。
|
||||
|
||||
- **5 个月**的开发
|
||||
- 最终产品中有 **100 万+ 行代码**
|
||||
- **零行手动编写的代码**——每一行都是由 Codex 智能体生成的
|
||||
- **用人类所需时间的约 1/10 构建**
|
||||
- 产品有**内部日常用户和外部 Alpha 测试者**
|
||||
- 它**交付、部署、出故障并得到修复**——全部由 Harness 内的智能体完成
|
||||
**常见模式**：
|
||||
- **执行前批准** - 在每个可能有后果的行动之前暂停 Agent 并请求明确确认
|
||||
- **执行后审查** - 让 Agent 行动但在提交或继续之前将结果浮出水面进行检查
|
||||
- **升级触发器** - 允许 Agent 在正常条件下自主运行，但在检测到特定风险信号时暂停并请求人工输入
|
||||
- **Hook 系统** - 允许操作员将任意逻辑附加到 Agent 循环中的特定生命周期事件
|
||||
|
||||
工程师的工作？设计 Harness。指定意图。提供反馈。不是编写代码。
|
||||
### 4. 可观测性和结构化反馈
|
||||
|
||||
## 三大支柱
|
||||
不留下可检查轨迹的 Agent 是无法调试、审计或改进的 Agent。
|
||||
|
||||
OpenAI 的框架将 Harness 工程组织为三个核心类别：
|
||||
**可观测性的实现**：
|
||||
- 每个模型调用、工具调用、内存读/写和决策分支的结构化日志
|
||||
- 将每个行动与其因果前因联系起来的执行轨迹
|
||||
- 聚合指标，如步数、令牌消耗、错误率和延迟分布
|
||||
|
||||
### 1. 上下文工程
|
||||
**双重目的**：
|
||||
1. **外部** - 支持调试、合规审计和事件后分析
|
||||
2. **内部** - 关闭将执行结果连接回产生它们的模块的反馈循环
|
||||
|
||||
上下文工程是关于确保智能体在正确的时间获得正确的信息。
|
||||
### 5. 配置、权限和策略编码
|
||||
|
||||
**静态上下文：**
|
||||
- 仓库本地文档（架构规范、API 契约、风格指南）
|
||||
- 编码项目特定规则的 `AGENTS.md` 或 `CLAUDE.md` 文件
|
||||
- 由 linter 验证的交叉链接设计文档
|
||||
Harness 必须不仅编码 Agent 可以做什么，还要编码它在什么条件下被允许做什么。
|
||||
|
||||
**动态上下文：**
|
||||
- 智能体可访问的可观测性数据（日志、指标、追踪）
|
||||
- 智能体启动时的目录结构映射
|
||||
- CI/CD 流水线状态和测试结果
|
||||
**分层配置**：
|
||||
- **用户级设置** - 编码个人偏好和信任边界
|
||||
- **项目级设置** - 指定哪些工具可用、哪些文件路径可访问以及哪些命令需要批准
|
||||
- **组织级设置** - 施加合规约束、成本上限和单个项目无法覆盖的数据处理规则
|
||||
|
||||
**关键规则：** 从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**
|
||||
### 6. 上下文预算管理
|
||||
|
||||
### 2. 架构约束
|
||||
上下文窗口仍然是任何 Agent 系统中最稀缺的共享资源。
|
||||
|
||||
这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。
|
||||
**有效管理策略**：
|
||||
- **摘要** - 将较旧的对话轮次和执行历史压缩为更短的表示
|
||||
- **基于优先级的驱逐** - 移除或降级与活动子任务相关性已衰减的上下文条目
|
||||
- **分阶段加载** - 确保详细的程序指导仅在检测到匹配的任务模式时才进入上下文
|
||||
|
||||
**依赖分层：**
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
## 生产系统中的 Harness
|
||||
|
||||
每层只能从其左侧的层导入。这不是建议——它由结构测试和 CI 验证强制执行。
|
||||
成熟的 Agent 系统在以下方面收敛于惊人相似的 Harness 结构集：
|
||||
|
||||
**约束强制执行工具：**
|
||||
- **确定性 linters**——自动标记违规的自定义规则
|
||||
- **基于 LLM 的审计员**——审查其他智能体代码的架构合规性
|
||||
- **结构测试**——像 ArchUnit，但用于 AI 生成的代码
|
||||
- **预提交钩子**——在提交任何代码前的自动检查
|
||||
| 维度 | 共同模式 |
|
||||
|------|----------|
|
||||
| **循环和控制流** | 围绕显式循环组织执行，带有终止控制 |
|
||||
| **沙箱** | 在不同粒度实现执行隔离 |
|
||||
| **人工监督** | 实现可配置的审批门和 hook 系统 |
|
||||
| **可观测性** | 产生结构化执行轨迹和日志 |
|
||||
| **配置和治理** | 跨多个范围分层配置 |
|
||||
| **上下文预算** | 通过摘要、分阶段加载和驱逐主动管理 |
|
||||
|
||||
**为什么约束能改善输出：** 矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
## Harness 作为认知环境
|
||||
|
||||
### 3. 熵管理（"垃圾回收"）
|
||||
Harness 的重要性超出了普通软件工程意义上的基础设施。它通过确定推理展开的环境来塑造 Agent 的有效认知。
|
||||
|
||||
这是最被低估的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定分歧、死代码堆积。
|
||||
> **关键主张**：Agent 可以知道、记住和做什么，不仅由模型权重固定，还由周围系统提供的访问、持久性和行动条件固定。
|
||||
|
||||
Harness 工程通过**定期清理智能体**来解决这个问题：
|
||||
- **文档一致性智能体**——验证文档与当前代码匹配
|
||||
- **约束违规扫描器**——找到逃过早期检查的代码
|
||||
- **模式强制执行智能体**——识别并修复与既定模式的偏差
|
||||
- **依赖审计员**——跟踪并解决循环或不必要的依赖
|
||||
### 理论视角
|
||||
|
||||
这些智能体按计划运行——每日、每周，或由特定事件触发——保持代码库对人类审查者和未来 AI 智能体都健康。
|
||||
1. **Norman 的认知人工制品** - Harness 在系统级别符合此描述。它不仅仅是用更多上下文或更多工具增强模型；它重组了模型面临的表征问题。
|
||||
|
||||
## 相关概念
|
||||
2. **Kirsh 的空间智能使用** - Harness 为 Agent 发挥类似作用。它是一个认知生态位，其中信息、工具、权限和程序被安排成使得期望行为更容易执行而不期望行为更难产生。
|
||||
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
- [[Entropy Management|熵管理]]
|
||||
- [[OpenAI Harness Engineering|OpenAI Harness 工程]]
|
||||
- [[Anthropic-Harness-Design|Anthropic Harness 设计]]
|
||||
- [[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
3. **分布式认知** - 操作智能分布在模型参数、外部记忆存储、可执行技能、协议定义、工具表面、监控系统和管理它们交互的运行时约束之间。
|
||||
|
||||
## 参考来源
|
||||
## 模块交互图
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. Anthropic - Harness design for long-running application development
|
||||
3. Martin Fowler - Harness engineering for coding agent users
|
||||
4. LangChain - Improving Deep Agents with harness engineering
|
||||
5. NxCode - Harness Engineering: The Complete Guide
|
||||
|
||||
|
||||
---
|
||||
记忆、技能和协议在 Harness 内部通过六个主要流动相互强化：
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
1. **记忆到技能** - 经验蒸馏
|
||||
2. **技能到记忆** - 执行记录
|
||||
3. **技能到协议** - 能力调用
|
||||
4. **协议到技能** - 能力生成
|
||||
5. **记忆到协议** - 策略选择
|
||||
6. **协议到记忆** - 结果同化
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Memory-Systems|记忆系统]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
- [[Agent-Protocols|智能体协议]]
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: "记忆系统"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "记忆系统"
|
||||
- "外部化"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 记忆系统
|
||||
|
||||
**记忆外部化**解决了智能体的时间负担问题。它将 Agent 的状态跨时间与短暂上下文解耦，使得连续性不再依赖于短暂的提示。
|
||||
|
||||
## 记忆的四大维度
|
||||
|
||||
|
||||
|
||||
### 1. 工作上下文
|
||||
|
||||
工作上下文是当前任务的实时中间状态：打开的文件、临时变量、活跃假设、部分计划和执行检查点。
|
||||
|
||||
- **快速变化**，如果过时就失去价值
|
||||
- **没有外部化**，一旦上下文窗口重置或进程被中断就会消失
|
||||
- **示例**：编码 Agent 中的草稿、终端状态和工作区工件
|
||||
|
||||
### 2. 情景经验
|
||||
|
||||
情景经验记录先前运行中发生的事情：决策点、工具调用、失败、结果和反思。
|
||||
|
||||
- **价值不仅是档案性的** - 检索的情节可以作为具体先例
|
||||
- **帮助 Agent 避免重复已知错误**
|
||||
- **为以后的抽象提供原材料**
|
||||
- **示例**：Reflexion 将失败尝试的反思摘要存储为可重用经验
|
||||
|
||||
### 3. 语义知识
|
||||
|
||||
语义知识存储在任何单个情节之外都存在的抽象：领域事实、一般启发式、项目约定和稳定的世界知识。
|
||||
|
||||
- **不是围绕特定时间和地点组织的**
|
||||
- **情景记忆说案例中发生了什么；语义记忆说什么倾向于在案例中成立**
|
||||
- **示例**：知识库和检索增强生成 (RAG) 语料库
|
||||
|
||||
### 4. 个性化记忆
|
||||
|
||||
个性化记忆跟踪关于特定用户、团队或环境的稳定信息：偏好、习惯、重复出现的约束和先前的交互。
|
||||
|
||||
- **不应折叠到 Agent 的一般自我改进存储中**
|
||||
- **用户特定的轨迹遵循不同的保留、检索和隐私规则**
|
||||
- **示例**：IFRAgent 从移动环境中的演示构建用户习惯存储库
|
||||
|
||||
## 记忆架构的演进
|
||||
|
||||
记忆架构可以被理解为四种广泛的范式：
|
||||
|
||||
### 1. 单片上下文
|
||||
|
||||
早期系统依赖单片上下文：所有相关历史或其摘要都直接保留在提示中。
|
||||
|
||||
- **优点**：透明且易于原型设计
|
||||
- **限制**：容量扩展性差，摘要漂移，状态随会话消失
|
||||
|
||||
### 2. 带有检索存储的上下文
|
||||
|
||||
占主导地位的下一步是仅将近期工作状态保留在上下文中，同时将长期轨迹存储在外部并按需检索。
|
||||
|
||||
- **解决原始容量问题**
|
||||
- **但将记忆质量转化为检索问题**
|
||||
- **改进方向**：GraphRAG 添加图结构、ENGRAM 压缩为潜在状态表示、SYNAPSE 在统一情景-语义图上使用扩散激活
|
||||
|
||||
### 3. 分层记忆和编排
|
||||
|
||||
一旦平面检索证明不足，系统就会转向分层记忆和编排。关键思想是，并非每个轨迹都应获得相同的保留策略或检索路径。
|
||||
|
||||
**两种主要设计趋势**：
|
||||
1. **时空维度中的资源解耦** - 借用操作系统逻辑，将热工作状态与较冷的长尾存储分离，并在任务需求变化时跨层交换信息
|
||||
2. **认知功能维度中的语义解耦** - 按功能或内容类型组织记忆，以便异构记录不会都通过同一通道路由
|
||||
|
||||
### 4. 自适应记忆系统
|
||||
|
||||
上述架构仍然严重依赖人工设计的启发式。自适应记忆系统更进一步，使模块、路由决策或检索策略对经验做出响应。
|
||||
|
||||
**两个方向**：
|
||||
1. **动态模块** - 一些系统在运行时调整架构本身
|
||||
2. **基于反馈的策略优化** - 其他系统保持架构相对固定但学习更好的控制策略
|
||||
|
||||
## Harness 时代的记忆需求
|
||||
|
||||
随着 Agent 演变为 Harness 时代，记忆系统不再仅仅是孤立的存储模块；相反，它们成为运行时协调连续性、程序重用和治理交互的基板。
|
||||
|
||||
**关键要求**：
|
||||
1. **状态与上下文的显式分离** - 不受限制的会话历史累积会导致模型失去跟踪
|
||||
2. **与技能系统集成** - 记忆存储先前执行的证据；技能仅在某些证据被提升为显式可重用程序时才开始
|
||||
3. **协议耦合** - 工具结果、批准、委托事件和外部状态转换通过协议化接口到达，但只有在被规范化并写入持久状态后才会成为记忆
|
||||
4. **共享和治理机制** - 一旦多个 Agent 依赖公共外部化状态，建立读写权限、解决冲突和控制访问配额就变得必要
|
||||
|
||||
## 记忆作为认知人工制品
|
||||
|
||||
现代 LLM 是无状态生成器：每次调用都以新的上下文开始，因此必须重建连续性而不是向前携带。
|
||||
|
||||
**记忆外部化改变了该任务的结构**：
|
||||
- 从**内部回忆问题**转变为**外部识别和检索问题**
|
||||
- 模型不再必须从其参数中恢复相关历史；它必须识别并使用记忆系统已经浮出水面的历史切片
|
||||
|
||||
**这解释了为什么检索质量比原始存储容量更重要**：
|
||||
- 拥有庞大存储但检索薄弱的系统仍然向模型呈现错误的问题表示
|
||||
- 具有强大索引、摘要和上下文选择的适度存储可以使下游推理显著更容易
|
||||
|
||||
**成功标准**：不是"我们保存了多少？"，而是"我们是否使当前决策清晰可辨？"
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
@@ -0,0 +1,324 @@
|
||||
---
|
||||
title: "Meta-Harness：模型 Harness 的端到端优化"
|
||||
source: "https://arxiv.org/html/2603.28052v1"
|
||||
author: "Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, Chelsea Finn"
|
||||
published: 2026
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- concepts
|
||||
- meta-harness
|
||||
- research
|
||||
raw_sources:
|
||||
- path: raw/Meta-Harness End-to-End Optimization of Model Harnesses.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# Meta-Harness：模型 Harness 的端到端优化
|
||||
|
||||
Meta-Harness 是斯坦福大学和 MIT 联合提出的一个外环系统，用于搜索 LLM 应用的 Harness 代码。它使用一个智能体提议者，通过文件系统访问所有先前候选的源代码、分数和执行轨迹。
|
||||
|
||||
> **核心洞察**：改变固定 LLM 周围的 Harness 可以在同一基准上产生 **6 倍的性能差距**。Harness——决定存储、检索和向模型显示什么的代码——通常与模型本身一样重要。
|
||||
|
||||
|
||||
|
||||
**图 1**：（左）在文本分类上，Meta-Harness 优于最佳的先前人工设计的 Harness（ACE）和现有的文本优化器（TTT-Discover、OpenEvolve），仅在 4 次评估后就匹配了次优方法的最终准确度。（右）在 TerminalBench-2 上，Meta-Harness 优于所有报告的 Claude Haiku 4.5 harness。
|
||||
|
||||
---
|
||||
|
||||
## 问题与动机
|
||||
|
||||
### Harness 工程的现状
|
||||
|
||||
Harness 工程是改进 LLM 周围代码以提高整体系统性能的实践。然而，尽管其重要性，Harness 工程仍然主要是人工的：从业者检查失败、调整启发式，并在少量设计上迭代。
|
||||
|
||||
### 现有文本优化方法的局限性
|
||||
|
||||
文本优化是一个自然的起点，但这些方法与 Harness 工程不匹配，因为它们通常在短期或严重压缩的反馈下操作：
|
||||
|
||||
- 一些方法仅以当前候选为条件
|
||||
- 其他方法主要依赖标量分数
|
||||
- 还有一些方法将反馈限制为短模板或 LLM 生成的摘要
|
||||
|
||||
这是一个实用的可扩展性选择，而不是长期依赖没有信息的证据。Harness 在长期范围内运作：关于存储什么、何时检索它或如何呈现它的单个选择可能在许多推理步骤后影响行为。
|
||||
|
||||
### 反馈规模对比
|
||||
|
||||
| 方法 | 历史 | 日志内容 | MTok/iter |
|
||||
|------|------|----------|-----------|
|
||||
| OPRO | 窗口 | 过去的（解决方案，分数）对 | 0.002 |
|
||||
| TextGrad | 最后 | 当前工件的文本反馈 | 0.015 |
|
||||
| AlphaEvolve | 窗口 | 程序数据库 + 评估分数 | 0.022 |
|
||||
| GEPA | 摘要 | 来自回滚轨迹的反思反馈 | 0.008 |
|
||||
| Feedback Descent | 摘要 | 比较 + 文本反馈 | 0.012 |
|
||||
| TTT-Discover | 窗口 | 先前的解决方案片段 | 0.026 |
|
||||
| **Meta-Harness** | **完整** | **所有日志和分数** | **10.0** |
|
||||
|
||||
在本文研究的设置中，单个评估可以产生多达 **10,000,000 个 token 的诊断信息**，大约比先前文本优化设置中使用的最大反馈预算高出三个数量级。
|
||||
|
||||
|
||||
|
||||
**图 2**：Meta-Harness 搜索循环。（1）智能体读取包含所有先前候选的源代码、执行轨迹和分数的文件系统，并提出新的 Harness。（2）我们在评估任务上评估提议的 Harness。（3）所有日志（提议的代码、推理轨迹、评估分数）都存储在文件系统的新目录中，循环重复。
|
||||
|
||||
---
|
||||
|
||||
## Meta-Harness 设计
|
||||
|
||||
Meta-Harness 是一个用于通过端到端搜索优化 Harness 的智能体 Harness。
|
||||
|
||||
### 目标形式化
|
||||
|
||||
Harness 是一个有状态的程序，它包装语言模型并确定模型在每一步看到什么上下文。目标很简单：找到使底层模型在目标任务分布上表现最佳的 Harness。
|
||||
|
||||
形式化地说，令 $M$ 表示固定语言模型，$\mathcal{X}$ 表示任务分布。对于 Harness $H$ 和任务实例 $x\sim\mathcal{X}$，我们执行回滚轨迹 $\tau\sim p_{M}(H,x)$。Harness 为 $M$ 构建提示，模型响应，Harness 在每次交互后更新其状态。特定任务的奖励函数 $r(\tau,x)$ 对轨迹进行评分。Harness 优化的目标是找到最大化期望最终奖励的 Harness：
|
||||
|
||||
$$
|
||||
H^{*}=\operatorname*{arg\,max}_{H}\mathbb{E}_{x\sim\mathcal{X},\tau\sim p_{M}(H,x)}\;r(\tau,x),
|
||||
$$
|
||||
|
||||
### 关键设计选择
|
||||
|
||||
1. **通过文件系统暴露完整历史** - 使能选择性诊断原始先前代码和执行轨迹，而不是从压缩的每候选摘要优化
|
||||
2. **智能体提议者** - 编码智能体决定检查什么并通过与代码库的直接交互验证编辑
|
||||
3. **无父代选择规则** - 提议者可以自由检查任何先前的 Harness 及其执行轨迹
|
||||
|
||||
### 文件系统存储
|
||||
|
||||
对于每个先前的候选 Harness，文件系统存储：
|
||||
- **源代码**
|
||||
- **评估分数**
|
||||
- **执行轨迹**（提示、工具调用、模型输出、状态更新）
|
||||
|
||||
文件系统通常远大于提议者的上下文窗口，因此提议者通过终端工具（如 grep 和 cat）查询它，而不是将其作为单个提示摄入。
|
||||
|
||||
### Meta-Harness 搜索循环
|
||||
|
||||
1. **智能体读取文件系统** - 包含所有先前候选的源代码、执行轨迹和分数
|
||||
2. **提议新 Harness** - 基于检查的历史提出改进
|
||||
3. **评估候选** - 在评估任务上测试提议的 Harness
|
||||
4. **存储日志** - 将所有日志（提议的代码、推理轨迹、评估分数）存储在文件系统中
|
||||
5. **重复循环**
|
||||
|
||||
### 算法伪代码
|
||||
|
||||
```
|
||||
算法 1 Meta-Harness 外环 Harness 优化
|
||||
|
||||
输入: 任务 X, LLM M, 提议者 P, 迭代次数 N
|
||||
|
||||
初始化: 种群 H ▶ 初始有效 Harness 集合
|
||||
初始化: 文件系统 D ← ∅ ▶ 存储代码、分数、轨迹
|
||||
|
||||
for H ∈ H do
|
||||
E_H ← Evaluate(H, M, X)
|
||||
D ← D ∪ {(H, E_H)}
|
||||
|
||||
for t = 1 ... N do
|
||||
提议者 P 查询文件系统 D ▶ 检查先前的 Harness 和分数
|
||||
提议者 P 提出 k 个新 Harness {H_1,…,H_k}
|
||||
for H ∈ {H_1,…,H_k} do
|
||||
if H 通过接口验证 then
|
||||
D ← D ∪ {(H, Evaluate(H, M, X))}
|
||||
|
||||
返回存储在 D 中的 Harness 的 Pareto 前沿
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 代码空间搜索的优势
|
||||
|
||||
Harness 优化发生在代码空间中，对检索、记忆或提示构建逻辑的小更改可能在许多步骤后影响行为，使得局部搜索启发式与此问题不匹配。
|
||||
|
||||
### 因果推理能力
|
||||
|
||||
通过检查执行轨迹，提议者通常可以推断**为什么**一个 Harness 失败以及哪些早期设计选择可能导致了失败，而不仅仅是**它**失败了。
|
||||
|
||||
提议者可以在算法结构级别修改 Harness，范围从对检索、记忆或提示构建逻辑的更改到完整程序重写，而不是填写模板或应用预定义的变异算子。
|
||||
|
||||
### 实际实现细节
|
||||
|
||||
在实验中，每个 Harness 是一个单文件 Python 程序，修改特定任务的提示、检索、记忆和编排逻辑。
|
||||
|
||||
- **提议者 P**：带有 Opus-4.6 的 Claude Code
|
||||
- **指导**：最小的特定领域技能，描述在哪里编写新 Harness、如何检查先前的 Harness 及其执行轨迹，以及它可以和不能修改哪些文件
|
||||
- **基础模型 M**：因领域而异，始终冻结
|
||||
- **典型运行**：在 20 次迭代中评估约 60 个 Harness
|
||||
|
||||
---
|
||||
|
||||
## 实验结果
|
||||
|
||||
### 4.1 在线文本分类
|
||||
|
||||
遵循在线文本分类设置：LLM 一次接收一个标记示例，更新其记忆，并在预留测试集上评估。使用 GPT-OSS-120B 作为 LLM 文本分类器。
|
||||
|
||||
**三个数据集**：
|
||||
1. **LawBench (Law)** - 从案例描述预测刑事指控（215 个类别）
|
||||
2. **Symptom2Disease (S2D)** - 从症状描述预测疾病（22 个类别）
|
||||
3. **USPTO-50k** - 从产物分子预测前体反应物（180 个类别）
|
||||
|
||||
**搜索设置**：
|
||||
- 从主要基线 Harness 初始化搜索种群：zero-shot、few-shot、ACE 和 MCE
|
||||
- 运行 20 次进化迭代，每次迭代两个候选，产生 40 个候选 Harness
|
||||
|
||||
|
||||
|
||||
**表 2**：所有 Harness 在三个数据集上的测试集指标。Ctx 表示上下文中的额外输入 token（千）。†：来自 51 的实现。↓：越低越好。Meta-Harness 在使用更小输入上下文的同时提高了在线文本分类准确度。
|
||||
|
||||
**结果**：
|
||||
- Meta-Harness 在 ACE（Agentic Context Engineering）的基础上提高了 **7.7 分**，同时使用的上下文 token 减少了 **4 倍**
|
||||
- 仅用 **4 次评估**就匹配了次优文本优化器的最终性能
|
||||
- 其最终准确度比所有基线高出 **10 分以上**
|
||||
|
||||
**消融研究**：
|
||||
|
||||
| 方法 | 分数 | 代码 | 摘要 | 轨迹 | 中位数 ↑ | 最佳准确度 ↑ | > ZS |
|
||||
|------|------|------|------|------|---------|-------------|------|
|
||||
| 仅分数 | ✓ | ✓ | × | × | 34.6 | 41.3 | 26 |
|
||||
| 分数 + 摘要 | ✓ | ✓ | ✓ | × | 34.9 | 38.7 | 23 |
|
||||
| Meta-Harness (完整) | ✓ | ✓ | - | ✓ | 50.0 | 56.7 | 39 |
|
||||
|
||||
**关键发现**：完整访问执行轨迹是使能 Harness 搜索的关键成分。摘要不能恢复丢失的信号，甚至可能通过压缩掉诊断有用的细节而造成伤害。
|
||||
|
||||
---
|
||||
|
||||
### 4.2 检索增强推理的 Harness
|
||||
|
||||
研究一个有点非标准的奥林匹克数学解决设置：用从大型语料库检索示例的能力增强模型。
|
||||
|
||||
**检索语料库**：
|
||||
- ≥ 500,000 个已解决问题，来自八个开源数据集
|
||||
- 仔细去重和去污染
|
||||
- 手动检查预留示例的顶级 BM25 检索
|
||||
|
||||
**搜索设置**：
|
||||
- 使用 Meta-Harness 在 250 道奥林匹克难度数学问题的搜索集上优化 40 次迭代
|
||||
- 产生 109 个候选检索 Harness
|
||||
- 从零样本、少样本和 ACE 初始化搜索种群
|
||||
- 基于搜索集性能使用 GPT-OSS-20B 选择单个 Harness
|
||||
|
||||
**评估设置**：
|
||||
- 在 200 道以前未见的 IMO 级问题上评估（IMO-AnswerBench、IMO-ProofBench、ArXivMath）
|
||||
- 除了 GPT-OSS-20B 外，还在搜索期间未见的四个模型上评估相同的检索 Harness：GPT-5.4-nano、GPT-5.4-mini、Gemini-3.1-Flash-Lite、Gemini-3-Flash
|
||||
|
||||
**结果**：
|
||||
|
||||
| 方法 | GPT-5.4n | GPT-5.4m | Gem-3.1FL | Gem-3F | GPT-20B | 平均 |
|
||||
|------|-----------|-----------|------------|---------|----------|------|
|
||||
| 无检索器 | 23.0 | 28.8 | 28.6 | 42.6 | 47.6 | 34.1 |
|
||||
| 密集检索 (k=1) | 27.1 (+4.1) | 24.5 (-4.3) | 31.3 (+2.7) | 42.3 (-0.3) | 46.9 (-0.7) | 34.4 (+0.3) |
|
||||
| 密集检索 (k=5) | 31.1 (+8.1) | 28.3 (-0.5) | 37.1 (+8.5) | 47.2 (+4.6) | 46.7 (-0.9) | 38.1 (+4.0) |
|
||||
| 随机少样本 | 23.1 (+0.1) | 24.5 (-4.3) | 31.0 (+2.4) | 40.4 (-2.2) | 41.8 (-5.8) | 32.2 (-1.9) |
|
||||
| BM25 检索 | 30.2 (+7.2) | 29.2 (+0.4) | 32.8 (+4.2) | 46.6 (+4.0) | 48.9 (+1.3) | 37.5 (+3.4) |
|
||||
| Meta-Harness | 31.7 (+8.7) | 30.4 (+1.6) | 34.9 (+6.3) | 46.3 (+3.7) | 50.6 (+3.0) | 38.8 (+4.7) |
|
||||
|
||||
**关键发现**：发现的检索 Harness 在所有五个预留模型上都优于无检索基线，平均增益为 **4.7 分**。它还匹配或超过了最强的固定基线，总体上比 BM25 检索高出 1.3 分，同时避免了在几个模型上观察到的密集检索和随机少样本提示的回归。
|
||||
|
||||
---
|
||||
|
||||
### 4.3 在 TerminalBench-2 上评估智能体编码 Harness
|
||||
|
||||
TerminalBench-2 在 89 个具有挑战性的任务上评估 LLM 智能体，这些任务需要在复杂依赖下的长期、完全自主执行，以及大量领域知识。
|
||||
|
||||
**搜索设置**：
|
||||
- 从两个强大的开放基线初始化搜索：Terminus 2 和 Terminus-KIRA
|
||||
- 在相同的 89 任务基准上执行搜索和最终评估
|
||||
- 将此基准用作发现问题
|
||||
- 通过手动检查和基于正则表达式的审计检查过拟合，以查找任务特定字符串泄漏到进化的 Harness 中
|
||||
|
||||
**结果**：
|
||||
|
||||
| Harness | 自动 | 通过率 (%) |
|
||||
|---------|------|-----------|
|
||||
| **Claude Opus 4.6** | | |
|
||||
| Claude Code | × | 58.0 |
|
||||
| Terminus 2 | × | 62.9 |
|
||||
| Mux | × | 66.5 |
|
||||
| Droid | × | 69.9 |
|
||||
| TongAgents | × | 71.9 |
|
||||
| MAYA-V2 | × | 72.1 |
|
||||
| Terminus-KIRA | × | 74.7 |
|
||||
| Capy | × | 75.3 |
|
||||
| ForgeCode | × | 81.8 |
|
||||
| Meta-Harness | ✓ | **76.4** |
|
||||
| **Claude Haiku 4.5** | | |
|
||||
| OpenHands | × | 13.9 |
|
||||
| Claude Code | × | 27.5 |
|
||||
| Terminus 2 | × | 28.3 |
|
||||
| Mini-SWE-Agent | × | 29.8 |
|
||||
| Terminus-KIRA | × | 33.7 |
|
||||
| Goose | × | 35.5 |
|
||||
| Meta-Harness | ✓ | **37.6** |
|
||||
|
||||
**关键发现**：
|
||||
- 在 Opus 4.6 上，Meta-Harness 发现的 Harness 达到 **76.4%** 通过率，超过了人工设计的 Terminus-KIRA（74.7%），在 TerminalBench-2 排行榜上所有 Opus 4.6 智能体中排名 **#2**
|
||||
- 在较弱的 Haiku 4.5 模型上，改进更大：Meta-Harness 达到 **37.6%**，比次优报告的智能体（Goose，35.5%）高出 **2.1 分**
|
||||
|
||||
---
|
||||
|
||||
## 提议者的定性行为
|
||||
|
||||
### A.1 文件访问统计
|
||||
|
||||
为验证提议者实质性地使用文件系统而不是默认局部编辑，记录了每次迭代的所有文件读取。
|
||||
|
||||
**结果摘要**：
|
||||
- 提议者每次迭代读取**中位数 82 个文件**（范围 69–99）
|
||||
- 大致均匀地分配在先前 Harness 源代码（41%）和执行轨迹（40%）之间
|
||||
- 其余部分用于分数摘要（6%）和其他文件（13%）
|
||||
|
||||
这证实了提议者的访问模式是非马尔可夫的：它例行检查大多数可用历史，而不是仅以最近的父代为条件。
|
||||
|
||||
### A.2 定性行为：对先前失败的因果推理
|
||||
|
||||
TerminalBench-2 搜索日志揭示了一个清晰的叙事弧线，其中提议者从自己的回归中学习。它不是通过局部编辑随机漫步，而是形成对早期候选为什么失败的明确诊断，然后转向更安全的设计模式。
|
||||
|
||||
#### 迭代 1–2：有希望的 bug 修复与提示编辑混淆
|
||||
|
||||
前两次迭代都将看似合理的结构修复与提示模板修改捆绑在一起，并且都从 64.4% 的 Terminus-KIRA 基线急剧回归。
|
||||
|
||||
#### 迭代 3：提议者识别混淆
|
||||
|
||||
到迭代 3，提议者明确推断回归主要不是由于结构 bug 修复本身：
|
||||
|
||||
> **假设**：__CMDEND__ 标记片段在长期任务上泄漏到 LLM 观察中，导致模型混淆并进入无限无工具调用循环。剥离这些标记 + 添加循环断路器将恢复浪费的步骤。
|
||||
|
||||
提议者注意到前两次失败的共同因素不是特定的 bug 修复，而是繁重的清理提示重写。因此，它恢复到原始提示并仅测试标记剥离和循环断路器。
|
||||
|
||||
#### 迭代 4–6：对诊断失败模式的直接修复仍然回归
|
||||
|
||||
接下来的三次迭代继续探测设计空间的相同部分，但现在有了关于为什么完成逻辑脆弱的更明确理论。
|
||||
|
||||
#### 迭代 7：获胜候选
|
||||
|
||||
在六次连续回归后，提议者从修改控制循环转向在循环开始前添加信息：
|
||||
|
||||
> **策略转变**：所有 6 次先前迭代都从 64.4% 基线回归，因为它们修改了完成流程、提示模板或观察处理。evo_env_bootstrap 采取不同的方法——纯粹是加法的。它在第一次 LLM 调用之前通过单个 shell 命令收集环境快照，并将其附加到初始提示。不更改其他方法。这应该在依赖繁重的任务上消除 3–5 次浪费的探索回合，而不会冒着在已经通过的任务上回归的风险。
|
||||
|
||||
这个候选是迄今为止最好的结果。重要的一点不仅是迭代 7 获胜，而且提议者阐明了**为什么**它应该更安全：它避免触摸先前脆弱的完成机制，而是添加主要在困难任务上有用的信息。
|
||||
|
||||
---
|
||||
|
||||
## 讨论
|
||||
|
||||
除了优于现有 Harness 外，Meta-Harness 还有几个实际优势：
|
||||
|
||||
1. **泛化能力**：发现的 Harness 泛化到分布外分类数据集和数学设置中未见的基础模型
|
||||
2. **时间效率**：一次搜索运行在几小时的挂钟时间内完成，但产生可读、可转移的策略，可以跨模型重用，包括未来更强的模型
|
||||
3. **可检查性**：代码空间中的过拟合也更可检查：脆弱的 if 链或硬编码的类映射在检查中可见，而权重空间过拟合则不是
|
||||
|
||||
更广泛地说，我们的结果表明 Meta-Harness 的主要优势不仅是代码搜索，而且是**对先前诊断经验的选择性访问**搜索。提议者不限于标量奖励或固定摘要；它可以检查原始代码、执行轨迹和先前失败，然后使用该信息形成和测试关于更改什么的假设。
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Managed-Agents-Decoupling-Brain-from-Hands|Managed Agents：将大脑与手分离]]
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
|
||||
---
|
||||
|
||||
## 项目资源
|
||||
|
||||
- 项目页面与交互式演示：[https://yoonholee.com/meta-harness/](https://yoonholee.com/meta-harness/)
|
||||
- 优化的 Harness：[https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact](https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact)
|
||||
@@ -1,110 +0,0 @@
|
||||
---
|
||||
title: 自我验证
|
||||
tags: [核心概念, 验证, Harness]
|
||||
source: [LangChain, Anthropic]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 自我验证
|
||||
|
||||
**自我验证**（Self-Verification）是[[Harness-Engineering|Harness 工程]]中的关键技术，使智能体能够通过运行中的反馈自我改进。当今的模型是卓越的自我改进机器，但它们没有自然地倾向于进入这种**构建-验证循环**。
|
||||
|
||||
## 核心概念
|
||||
|
||||
### 最常见的失败模式
|
||||
|
||||
LangChain 团队观察到的最常见失败模式是：智能体编写解决方案、重读自己的代码、确认看起来没问题，然后停止。
|
||||
|
||||
测试是自主智能体编码的关键部分。它有助于测试整体正确性，同时为智能体提供信号来进行爬山优化。
|
||||
|
||||
## 构建-验证循环
|
||||
|
||||
LangChain 向系统提示中添加了关于如何解决问题的指导：
|
||||
|
||||
### 阶段 1：规划与发现
|
||||
阅读任务、扫描代码库，并基于任务规格和如何验证解决方案构建初始计划。
|
||||
|
||||
### 阶段 2：构建
|
||||
在考虑验证的情况下实现计划。如果测试不存在则构建测试，并测试愉快路径和边缘情况。
|
||||
|
||||
### 阶段 3：验证
|
||||
运行测试、阅读完整输出、与要求的内容进行比较（而不是与你自己的代码）。
|
||||
|
||||
### 阶段 4：修复
|
||||
分析任何错误、重新访问原始规格，并修复问题。
|
||||
|
||||
## LangChain 的实现
|
||||
|
||||
### PreCompletionChecklistMiddleware
|
||||
|
||||
除了提示外，确定性上下文注入有助于智能体验证它们的工作。LangChain 使用 `PreCompletionChecklistMiddleware` 在智能体退出前拦截它，并提醒它对任务规格运行验证通过。
|
||||
|
||||
这类似于 [Ralph Wiggum Loop|Ralph Wiggum 循环]]，其中一个钩子在智能体退出时强制其继续执行，用于验证。
|
||||
|
||||
|
||||
|
||||
### 强调测试
|
||||
|
||||
LangChain 真正专注于测试，因为它在每次迭代中推动变化。他们发现，测试必须是智能体工作流程的核心部分，而不是事后想法。
|
||||
|
||||
## 环境上下文工程
|
||||
|
||||
Harness 工程的一部分是**为上下文工程构建良好的交付机制。** Terminal Bench 任务带有目录结构、内置工具和严格的超时。
|
||||
|
||||
### 1. 目录上下文与工具
|
||||
`LocalContextMiddleware` 在智能体启动时运行，映射 `cwd` 和其他父+子目录。运行 `bash` 命令来查找工具如 `Python` 安装。上下文发现和搜索容易出错，因此注入上下文减少了这个错误表面并帮助**将智能体引导到其环境中。**
|
||||
|
||||
### 2. 教导智能体编写可测试的代码
|
||||
智能体不知道它们的代码需要如何可测试。添加提示说它们的工作将根据程序化测试来衡量，类似于提交代码时。例如，提及文件路径的任务规格应该被精确遵循，以便解决方案在自动化评分步骤中工作。强调边缘情况的提示有助于智能体避免仅检查"愉快路径"情况。强制模型符合测试标准是避免随着时间推移"烂泥堆积"的强大策略。
|
||||
|
||||
### 3. 时间预算
|
||||
注入时间预算警告以推动智能体完成工作并转向验证。智能体在时间估计方面是出了名的糟糕，因此这种启发式在这种环境中有所帮助。现实世界编码通常没有严格的时间限制，但如果不添加任何约束知识，智能体就不会在时间范围内工作。
|
||||
|
||||
## 循环检测
|
||||
|
||||
智能体一旦决定了一个计划就可能变得短视，导致"末日循环"，对同一破碎方法进行小幅变异（在某些轨迹中超过 10 次以上）。
|
||||
|
||||
LangChain 使用 `LoopDetectionMiddleware`，通过工具调用钩子跟踪每个文件的编辑次数。它在对同一文件进行 `N` 次编辑后添加上下文如"……考虑重新考虑你的方法"。这可以帮助智能体从末日循环中恢复，尽管如果模型认为正确的话它可以继续沿着相同的路径前进。
|
||||
|
||||
重要提示：这是一种设计启发式，围绕当今感知的模型问题进行工程设计。随着模型改进，这些护栏可能会变得不必要，但今天帮助智能体正确和自主地执行。
|
||||
|
||||
## 推理三明治
|
||||
|
||||
推理模型可以自主运行数小时，因此必须决定在每个子任务上花费多少计算。你可以在每个任务上使用最大推理预算，但大多数工作可以从优化推理计算支出中受益。
|
||||
|
||||
Terminal Bench 超时限制创造了一个权衡。更多推理有助于智能体评估每个步骤，但可以燃烧超过 2 倍以上的 token/时间。`gpt-5.2-codex` 有 4 种推理模式，`low`、`medium`、`high` 和 `xhigh`。
|
||||
|
||||
LangChain 发现推理有助于规划以充分理解问题，一些 Terminal Bench 任务非常困难。一个好的计划有助于更快地得到可行的解决方案。
|
||||
|
||||
后期验证也从更多推理中受益，以捕获错误并提交解决方案。作为一种启发式，选择 xhigh-high-xhigh"**推理三明治**"作为基线。
|
||||
|
||||
|
||||
|
||||
**在规划和验证上花费更多的推理计算**
|
||||
|
||||
仅在 `xhigh` 运行由于智能体超时而得分较差，为 `53.9%`，相比之下在 `high` 为 `63.6%`。在推理预算分割的试验运行中没有大的差异，因此坚持使用他们的方法，将分数推到 `66.5%`。
|
||||
|
||||
## Harness 工程师的目的
|
||||
|
||||
**Harness 工程师的目的：准备和交付上下文，使智能体能够自主完成工作。**
|
||||
|
||||
智能体对其环境、约束和评估标准了解得越多，它们就能越好地自主自我指导工作。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Build-Verify Loop|构建-验证循环]]
|
||||
- [[Reasoning Sandwich|推理三明治]]
|
||||
- [[Doom Loop|末日循环]]
|
||||
- [[Loop Detection|循环检测]]
|
||||
- [[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. LangChain - Improving Deep Agents with harness engineering
|
||||
2. Anthropic - Harness design for long-running application development
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
title: "技能系统"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "技能系统"
|
||||
- "外部化"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 技能系统
|
||||
|
||||
**技能外部化**解决了智能体的程序负担问题。它将任务特定的知识打包成显式的可发现、可加载、可修订和可组合的人工制品，而不是要求模型在每次尝试任务时重新生成工作流、默认值和约束。
|
||||
|
||||
## 技能的三大组成部分
|
||||
|
||||
|
||||
|
||||
### 1. 操作程序
|
||||
|
||||
操作程序是任务骨架：将复杂工作分解为步骤、阶段、依赖关系和停止条件。
|
||||
|
||||
- **解决 LLM Agent 中的常见失败模式**：许多错误不是来自行动级别的无能，而是来自流程级别的不稳定
|
||||
- **使执行更少即兴创作**：Agent 可以在中断后恢复，跨上下文或协作者移交工作，并在不从记忆重建整个工作流的情况下恢复状态
|
||||
- **在长视野、多 Agent 和生产设置中最重要**，其中流程稳定性通常比瞬间流畅性更重要
|
||||
|
||||
### 2. 决策启发式
|
||||
|
||||
如果程序定义了执行的骨架，决策启发式管理分支处发生的情况。
|
||||
|
||||
- **实际任务很少作为固定管道展开**：工具失败、观察有噪声、几个局部合理的行动可能竞争
|
||||
- **在这些条件下，良好的性能依赖于从经验中得出的实用经验法则**，而不是仅靠穷举搜索
|
||||
- **捕获专家风格**：首先尝试什么，何时后退，什么证据足够，以及当多个路径仍然可行时偏好哪些权衡
|
||||
|
||||
### 3. 规范性约束
|
||||
|
||||
第三个组成部分是规范性约束：程序被视为可接受的条件。
|
||||
|
||||
- **工作流在技术上可能有效但仍然不合规、不安全或操作上错误**
|
||||
- **在实际部署中，执行受到测试要求、范围限制、访问限制、可追溯性期望和特定领域操作规则的约束**
|
||||
- **一旦外部化，这些约束就不再仅仅是事后评估标准**，而是成为技能本身的一部分
|
||||
- **编码不仅是如何执行任务，还有如何在组织和安全边界内执行任务**
|
||||
|
||||
## 从执行原语到能力包
|
||||
|
||||
技能系统不是孤立出现的，但也不应与工具使用混为一谈。历史上，技能在两个早期发展的下游：可靠的行动调用和大规模行动选择。
|
||||
|
||||
### 阶段 1：原子执行原语
|
||||
|
||||
第一阶段为语言模型配备可靠的行动执行，例如通过结构化工具调用和函数调用接口。
|
||||
|
||||
- **关键成就**：稳定访问原子行动单元
|
||||
- **不提供**：完成更广泛任务类别的显式可重用程序
|
||||
- **单元是行动原语**，而不是技能
|
||||
|
||||
### 阶段 2：大规模原语选择
|
||||
|
||||
随着可调用工具数量的增长，问题从调用转移到选择。
|
||||
|
||||
- **主要进步**：模型可以检索、排名和动态在大型工具集合中选择
|
||||
- **单元仍然是工具**，而不是程序
|
||||
- **即使多步行为开始出现，完成任务类别的知识在很大程度上仍然隐含在提示或参数中**，而不是外部化为有界的可重用人工制品
|
||||
|
||||
### 阶段 3：作为打包专长的技能
|
||||
|
||||
第三阶段标志着抽象的进一步转变。中心问题不再是模型是否可以调用函数或检索适当的 API，而是完成一类任务所需的知识是否可以打包成可重用的能力单元。
|
||||
|
||||
**关键转换**：
|
||||
- 能力不再主要被视为对工具或 API 的访问
|
||||
- 能力越来越被视为打包的程序知识，可以跨任务加载、重用和组合
|
||||
- 基础能力单元不再是孤立的工具调用，而是以可重用程序指导和执行结构为中心的更高级别人工制品
|
||||
|
||||
## 技能如何外部化
|
||||
|
||||
技能外部化不仅限于写下指令。在成熟的 Agent 系统中，关键问题是程序专长是否可以以在运行时可发现、可加载、可解释、可绑定和可执行的形式表示。
|
||||
|
||||
### 1. 规范
|
||||
|
||||
技能的外部化始于规范层。典型形式包括 SKILL.md、指令文件、清单或其他声明性规范人工制品。
|
||||
|
||||
**格式良好的技能规范应涵盖五类信息**：
|
||||
1. 能力边界
|
||||
2. 适用范围
|
||||
3. 前置条件
|
||||
4. 执行约束
|
||||
5. 示例和反例
|
||||
|
||||
### 2. 发现
|
||||
|
||||
一旦技能成为显式人工制品，它们自然会引入注册和发现问题。
|
||||
|
||||
**发现机制**：
|
||||
- 本地存储库、组织注册表或平台级市场
|
||||
- 基于任务目标、上下文状态和环境条件的语义检索、结构化元数据、任务分解或这些策略的组合
|
||||
|
||||
### 3. 渐进式披露
|
||||
|
||||
技能的发现并不意味着其全部内容应立即注入到活动上下文中。
|
||||
|
||||
**分层形式**：
|
||||
1. **最小级别** - 模型仅看到技能的名称和简要描述
|
||||
2. **更深级别** - 公开清单类信息，如适用条件、所需的先决条件和主要约束
|
||||
3. **最深级别** - 系统加载完整指南，包括详细程序、异常处理、示例和支持文件
|
||||
|
||||
### 4. 执行绑定
|
||||
|
||||
技能仍然是认知级别的描述，除非它连接到可执行行动。实际任务完成取决于绑定过程，该过程将技能的自然语言或结构化规范转换为当前环境中的具体操作。
|
||||
|
||||
### 5. 组合
|
||||
|
||||
技能系统的价值在技能可以组合时得到最充分的体现。与原子工具不同，技能可以参与更高级别的结构化协调。
|
||||
|
||||
**常见组合模式**：
|
||||
- 串行执行
|
||||
- 并行分工
|
||||
- 条件路由
|
||||
- 在更高级别技能中递归调用子技能
|
||||
|
||||
## 技能获取和演化
|
||||
|
||||
技能系统之所以重要，不仅因为它存储了创作的指令，还因为它提供了将成功行为转化为可重用专长的途径。
|
||||
|
||||
**四种获取途径**：
|
||||
|
||||
1. **创作** - 仍然是技能进入当前系统的最常见和最稳定的途径
|
||||
2. **蒸馏** - 也可以从历史轨迹、实践痕迹或其他存储经验中诱导
|
||||
3. **发现** - 除了手动创作和事后蒸馏，Agent 还可以通过环境交互自主发现新技能
|
||||
4. **组合** - 最后，技能可以通过组合演化
|
||||
|
||||
## 边界条件
|
||||
|
||||
技能外部化改进了重用和治理，但它不能保证可靠性。
|
||||
|
||||
**主要边界条件**：
|
||||
1. **语义对齐** - 模型可能遵循技能的字面措辞，同时仍然缺少任务的真正目标
|
||||
2. **可移植性和陈旧性** - 技能在环境中的有效性不能被假设
|
||||
3. **不安全组合** - 组合使技能更强大，但也创造了新的风险
|
||||
4. **上下文相关的降级** - 技能执行可能在长时间交互中降级
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Memory-Systems|记忆系统]]
|
||||
- [[Agent-Protocols|智能体协议]]
|
||||
@@ -1,201 +0,0 @@
|
||||
---
|
||||
title: 构建你的第一个 Harness
|
||||
tags: [实践指南, 入门, Harness]
|
||||
source: [NxCode, OpenAI, Martin Fowler]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 构建你的第一个 Harness
|
||||
|
||||
本文提供了构建 Harness 的实用框架，从个人开发者到工程组织的三个级别。
|
||||
|
||||
---
|
||||
|
||||
## Level 1：基础 Harness（单个开发者）
|
||||
|
||||
如果你正在为个人项目使用 Claude Code、Cursor 或 Codex：
|
||||
|
||||
### 需要设置的内容
|
||||
|
||||
- `CLAUDE.md` 或 `.cursorrules` 文件，包含项目约定
|
||||
- 用于 linting 和格式化的预提交钩子
|
||||
- 智能体可以运行以自我验证的测试套件
|
||||
- 具有一致命名的清晰目录结构
|
||||
|
||||
**设置时间：** 1-2 小时
|
||||
**影响：** 防止最常见的智能体错误
|
||||
|
||||
### 快速入门清单
|
||||
|
||||
1. **创建 CLAUDE.md**
|
||||
```markdown
|
||||
# 项目约定
|
||||
|
||||
## 代码风格
|
||||
- 使用 TypeScript，严格模式
|
||||
- 使用 2 空格缩进
|
||||
- 函数名使用驼峰命名
|
||||
|
||||
## 测试
|
||||
- 所有新代码必须有测试
|
||||
- 提交前运行 `npm test`
|
||||
|
||||
## 目录结构
|
||||
- src/ - 源代码
|
||||
- tests/ - 测试文件
|
||||
- docs/ - 文档
|
||||
```
|
||||
|
||||
2. **设置预提交钩子**
|
||||
```bash
|
||||
# 使用 husky 或 pre-commit
|
||||
npm install husky --save-dev
|
||||
npx husky install
|
||||
```
|
||||
|
||||
3. **确保测试存在**
|
||||
- 即使是简单的集成测试也比没有好
|
||||
- 智能体需要可以运行的东西来验证其工作
|
||||
|
||||
---
|
||||
|
||||
## Level 2：团队 Harness（小团队）
|
||||
|
||||
对于共享代码库的 3-10 名开发者的团队：
|
||||
|
||||
### 在 Level 1 基础上添加
|
||||
|
||||
- 包含团队范围约定的 `AGENTS.md`
|
||||
- CI 强制执行的架构约束
|
||||
- 常见任务的共享提示模板
|
||||
- 由 linter 验证的文档即代码
|
||||
- 专门针对智能体生成的 PR 的代码审查清单
|
||||
|
||||
**设置时间：** 1-2 天
|
||||
**影响：** 整个团队的智能体行为一致
|
||||
|
||||
### AGENTS.md 结构建议
|
||||
|
||||
```markdown
|
||||
# AGENTS.md
|
||||
|
||||
本文档包含智能体在此代码库中工作的约定。
|
||||
|
||||
## 1. 架构原则
|
||||
- 我们使用分层架构：Types → Config → Repo → Service → API
|
||||
- 不要跨层导入
|
||||
- 所有外部依赖通过 Providers 访问
|
||||
|
||||
## 2. 编码标准
|
||||
- [具体规则...]
|
||||
|
||||
## 3. 测试策略
|
||||
- [具体指南...]
|
||||
|
||||
## 4. 审查清单
|
||||
- [智能体在提交前应检查的内容...]
|
||||
```
|
||||
|
||||
### 共享提示模板
|
||||
|
||||
创建一个 `prompts/` 目录，包含常见任务：
|
||||
- `prompts/add-new-feature.md`
|
||||
- `prompts/fix-bug.md`
|
||||
- `prompts/write-tests.md`
|
||||
- `prompts/refactor-code.md`
|
||||
|
||||
---
|
||||
|
||||
## Level 3：生产 Harness（工程组织）
|
||||
|
||||
对于运行数十个并发智能体的组织：
|
||||
|
||||
### 在 Level 2 基础上添加
|
||||
|
||||
- 自定义中间件层（循环检测、推理优化）
|
||||
- 可观测性集成（智能体读取日志和指标）
|
||||
- 计划运行的熵管理智能体
|
||||
- Harness 版本控制和 A/B 测试
|
||||
- 智能体性能监控仪表板
|
||||
- 智能体陷入困境时的升级策略
|
||||
|
||||
**设置时间：** 1-2 周
|
||||
**影响：** 智能体作为自主贡献者运作
|
||||
|
||||
---
|
||||
|
||||
## 常见 Harness 工程错误
|
||||
|
||||
### 1. 过度工程化控制流
|
||||
|
||||
> "如果你过度工程化控制流，下一个模型更新会破坏你的系统。"
|
||||
|
||||
模型快速改进。2024 年需要复杂管道的能力现在由单个上下文窗口提示处理。构建你的 Harness 为**可剥离的**——当模型变得足够智能不需要时，你应该能够移除"智能"逻辑。
|
||||
|
||||
### 2. 将 Harness 视为静态的
|
||||
|
||||
Harness 需要随模型一起演进。当新模型版本改进推理时，你的推理优化中间件可能会适得其反。每次重大模型更新时审查和更新 Harness 组件。
|
||||
|
||||
### 3. 忽略文档层
|
||||
|
||||
最有影响力的 Harness 改进通常是最简单的：**更好的文档**。如果你的 `AGENTS.md` 含糊，你的智能体输出也会含糊。投资于精确、机器可读的文档，作为智能体的地面真理。
|
||||
|
||||
### 4. 没有反馈循环
|
||||
|
||||
没有反馈的 Harness 是一个笼子，而不是指南。智能体需要知道它何时成功何时失败。内置：
|
||||
- 任务完成前的自我验证步骤
|
||||
- 作为智能体工作流一部分的测试执行
|
||||
- 按任务类型的智能体成功率指标
|
||||
|
||||
### 5. 仅人类可读的文档
|
||||
|
||||
如果你的架构决策存在于人们的头脑中或智能体无法访问的 Confluence 页面中，Harness 就有差距。**智能体需要的一切都必须在仓库中。**
|
||||
|
||||
---
|
||||
|
||||
## 从哪里开始
|
||||
|
||||
### 如果你是单个开发者
|
||||
|
||||
1. 从 Level 1 开始
|
||||
2. 创建一个简单的 `CLAUDE.md`
|
||||
3. 设置基础预提交钩子
|
||||
4. 添加一个简单的测试套件
|
||||
5. 迭代——观察智能体失败的地方并加以修复
|
||||
|
||||
### 如果你是一个团队
|
||||
|
||||
1. 首先就 Level 1 基础达成一致
|
||||
2. 一起编写 `AGENTS.md` 的初稿
|
||||
3. 识别最常见的 3 个智能体失败模式
|
||||
4. 为这些模式构建前 3 个约束/检查
|
||||
5. 每 2 周回顾一次什么有效/什么无效
|
||||
|
||||
### 如果你是一个组织
|
||||
|
||||
1. 从一些试点团队开始
|
||||
2. 收集什么有效的模式
|
||||
3. 构建可重用的 Harness 组件库
|
||||
4. 投资于可观测性和指标
|
||||
5. 建立 Harness 迭代的反馈循环
|
||||
|
||||
---
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
- [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. NxCode - Harness Engineering: The Complete Guide
|
||||
2. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
3. Martin Fowler - Harness engineering for coding agent users
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: "LangChain Harness 工程实践"
|
||||
source: "https://blog.langchain.com/improving-deep-agents-with-harness-engineering/"
|
||||
author: "LangChain"
|
||||
published: 2026-02-18
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- practices
|
||||
- harness-engineering
|
||||
- langchain
|
||||
raw_sources:
|
||||
- path: raw/Improving Deep Agents with harness engineering.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# LangChain Harness 工程实践
|
||||
|
||||
本文记录了 LangChain 团队如何通过仅改进 Harness，将他们的编码智能体在 Terminal Bench 2.0 上从第 30 名提升到第 5 名。核心要点：**自我验证和追踪帮助巨大**。
|
||||
|
||||
## 核心成果
|
||||
|
||||
- **基准测试**：Terminal Bench 2.0
|
||||
- **提升幅度**：从 52.8 分提升到 66.5 分（+13.7 分）
|
||||
- **模型保持不变**：gpt-5.2-codex
|
||||
- **仅修改 Harness**：系统提示词、工具、中间件
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Harness 工程的目标
|
||||
|
||||
Harness 的目标是塑造模型固有的尖峰智力以适应我们关心的任务。**Harness 工程**是关于系统的，你在模型周围构建工具以优化目标，如任务性能、token 效率、延迟等。设计决策包括系统提示词、工具选择和执行流程。
|
||||
|
||||
但你应该如何改变 Harness 以改进智能体？
|
||||
|
||||
在 LangChain，他们使用 [Traces](https://docs.langchain.com/langsmith/observability-quickstart) 来大规模理解智能体失败模式。今天的模型在很大程度上是黑盒，它们的内部机制难以解释。但我们可以在文本空间中看到它们的输入和输出，然后将其用于我们的改进循环。
|
||||
|
||||
---
|
||||
|
||||
## 实验设置与 Harness 上的旋钮
|
||||
|
||||
使用 Terminal Bench 2.0（一个现在标准的基准测试来评估智能体编码）。它有 89 个任务，涵盖机器学习、调试和生物学等领域。使用 Harbor 来编排运行。它启动沙箱（Daytona），与智能体循环交互，并运行验证 + 评分。
|
||||
|
||||
每个智能体操作都存储在 LangSmith 中。它还包括延迟、token 计数和成本等指标。
|
||||
|
||||
### 我们可以转动的旋钮
|
||||
|
||||
智能体 Harness 有很多旋钮：系统提示词、工具、钩子/中间件、技能、子智能体委托、记忆系统等等。LangChain 有意压缩优化空间，专注于三个：**系统提示词、工具**和[**中间件**](https://docs.langchain.com/oss/python/langchain/middleware/overview)（他们对模型和工具调用周围钩子的术语）。
|
||||
|
||||
从默认提示词和标准工具+中间件开始。这在 GPT-5.2-Codex 上得分 52.8%。一个可靠的分数，刚好在今天排行榜前 30 名之外，但有增长空间。
|
||||
|
||||
|
||||
|
||||
### 追踪分析器技能
|
||||
|
||||
LangChain 希望追踪分析可重复，因此将其做成了智能体技能。这作为他们的**跨运行分析错误并对 Harness 进行改进**的方案。流程是：
|
||||
|
||||
1. 从 LangSmith 获取实验追踪
|
||||
2. 生成并行错误分析智能体 → 主智能体综合发现 + 建议
|
||||
3. 聚合反馈并对 Harness 进行有针对性的更改
|
||||
|
||||
这类似于 [boosting](https://en.wikipedia.org/wiki/Boosting_\(machine_learning\))，它专注于先前运行的错误。人类在第 3 步中可能非常有帮助（尽管不是必需的）来验证和讨论提议的更改。过度拟合到任务的更改对泛化不利，并可能导致其他任务的回归。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 实际改进智能体性能的因素
|
||||
|
||||
自动化追踪分析允许 LangChain [调试智能体出错的地方](https://www.langchain.com/conceptual-guides/agent-observability-powers-agent-evaluation)。问题包括推理错误、不遵循任务指令、缺少测试和验证、超时等。
|
||||
|
||||
### 构建与自我验证
|
||||
|
||||
今天的模型是卓越的自我改进机器。
|
||||
|
||||
**自我验证允许智能体通过运行内的反馈自我改进。** 然而，它们没有自然倾向进入这个**构建-验证循环。**
|
||||
|
||||
最常见的失败模式是，智能体编写了一个解决方案，重新阅读自己的代码，确认看起来没问题，然后停止。测试是自主智能体编码的关键部分。它有助于测试整体正确性，同时为智能体提供信号以进行爬山优化。
|
||||
|
||||
LangChain 在系统提示词中添加了关于如何解决问题的指导：
|
||||
|
||||
1. **规划与发现**：阅读任务，扫描代码库，基于任务规范和如何验证解决方案构建初始计划。
|
||||
2. **构建**：考虑验证来实现计划。如果测试不存在则构建测试，测试快乐路径和边缘情况。
|
||||
3. **验证**：运行测试，阅读完整输出，与要求的内容进行比较（不是与你自己的代码比较）。
|
||||
4. **修复**：分析任何错误，重新审视原始规范，并修复问题。
|
||||
|
||||
他们真正专注于测试，因为它在每次迭代中推动更改。发现除了提示词之外，确定性上下文注入有助于智能体验证它们的工作。使用 `PreCompletionChecklistMiddleware` 在智能体退出前拦截它，并提醒它对任务规范运行验证传递。这类似于 [Ralph Wiggum Loop](https://ghuntley.com/loop/)，其中一个钩子强制智能体在退出时继续执行，他们用它来进行验证。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 为智能体提供关于其环境的上下文
|
||||
|
||||
Harness 工程的一部分是**构建一个良好的上下文工程交付机制。** Terminal Bench 任务带有目录结构、内置工具和严格的超时。
|
||||
|
||||
1. **目录上下文与工具**：`LocalContextMiddleware` 在智能体启动时运行以映射 `cwd` 和其他父/子目录。运行 `bash` 命令来查找工具，如 Python 安装。上下文发现和搜索容易出错，因此注入上下文减少了这个错误表面并帮助**将智能体引导到其环境中。**
|
||||
2. **教智能体编写可测试的代码**：智能体不知道它们的代码需要如何可测试。添加提示词说它们的工作将根据编程测试来衡量，类似于提交代码时。例如，提到文件路径的任务规范应该完全遵循，以便解决方案在自动化评分步骤中工作。强调边缘情况的提示词有助于智能体避免只检查"快乐路径"情况。强制模型符合测试标准是避免随着时间推移"残渣 buildup"的强大策略。
|
||||
3. **时间预算**：注入时间预算警告以推动智能体完成工作并转向验证。智能体在时间估计方面出了名的差，因此这种启发式在这种环境中有帮助。现实世界的编码通常没有严格的时间限制，但如果不添加任何约束知识，智能体就不会在时间范围内工作。
|
||||
|
||||
智能体对其环境、约束和评估标准了解得越多，它们就能越好地自主自我指导工作。
|
||||
|
||||
> **Harness 工程师的目的**：准备并交付上下文，以便智能体可以自主完成工作。
|
||||
|
||||
---
|
||||
|
||||
### 鼓励智能体退后一步并重新考虑计划
|
||||
|
||||
智能体一旦决定了一个计划可能会短视，导致"末日循环"，对相同的破碎方法进行小的变化（在某些追踪中 10+ 次）。
|
||||
|
||||
使用 `LoopDetectionMiddleware` 通过工具调用钩子跟踪每个文件的编辑计数。它在对同一文件进行 `N` 次编辑后添加诸如"……考虑重新考虑你的方法"之类的上下文。这可以帮助智能体从末日循环中恢复，尽管如果模型认为正确，它可以继续沿着相同的路径前进。
|
||||
|
||||
重要提示。这是一种设计启发式，围绕今天感知到的模型问题进行工程设计。随着模型改进，这些护栏可能会变得不必要，但今天有助于智能体正确且自主地执行。
|
||||
|
||||
---
|
||||
|
||||
### 选择在推理上花费多少计算
|
||||
|
||||
推理模型可以自主运行数小时，因此必须决定在每个子任务上花费多少计算。可以在每个任务上使用最大推理预算，但大多数工作可以从优化推理计算花费中受益。
|
||||
|
||||
Terminal Bench 超时限制创造了一个权衡。更多推理帮助智能体评估每个步骤，但可能燃烧超过 2 倍的 token/时间。`gpt-5.2-codex` 有 4 种推理模式：`low`、`medium`、`high` 和 `xhigh`。
|
||||
|
||||
发现推理有助于规划以完全理解问题，一些 Terminal Bench 任务非常困难。一个好的计划有助于更快地达到可行的解决方案。
|
||||
|
||||
后期验证也受益于更多推理以捕获错误并提交解决方案。作为一种启发式，选择 xhigh-high-xhigh"**推理三明治**"作为基线。
|
||||
|
||||
|
||||
|
||||
仅在 `xhigh` 运行得分很差，为 `53.9%`，因为智能体超时，相比之下在 `high` 运行得分为 `63.6%`。在推理预算拆分之间的试运行中没有大的差异，因此坚持使用将分数推到 `66.5%` 的方法。
|
||||
|
||||
模型的自然方法是**自适应推理**，在 [Claude](https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking) 和 [Gemini](https://ai.google.dev/gemini-api/docs/thinking) 模型中看到，模型决定在推理上花费多少计算。
|
||||
|
||||
在多模型 Harness 中，平衡推理预算可以表现为使用大模型进行规划并[交接](https://docs.langchain.com/oss/python/langchain/multi-agent/handoffs)给小模型进行实现。
|
||||
|
||||
---
|
||||
|
||||
## 构建智能体 Harness 的实用要点
|
||||
|
||||
智能体的设计空间很大。以下是 LangChain 从实验和整体构建 deepagents 中得出的一些一般原则：
|
||||
|
||||
1. **代表智能体进行上下文工程**。上下文组装对于今天的智能体仍然很困难，尤其是在看不见的环境中。用目录结构、可用工具、编码最佳实践和问题解决策略等上下文引导模型，有助于减少搜索不佳和规划中可避免错误的错误表面。
|
||||
2. **帮助智能体自我验证其工作**。模型偏向于它们第一个看似合理的解决方案。强烈提示它们通过运行测试和改进解决方案来验证其工作。这在没有人类在循环中的自主编码系统中尤其重要。
|
||||
3. **追踪作为反馈信号**。追踪允许智能体自我评估和调试自己。一起调试工具和推理很重要（例如：模型走错路径是因为它们缺少工具或关于如何做某事的指令）。
|
||||
4. **在短期内检测并修复坏模式**。今天的模型并不完美。Harness 设计者的工作是围绕今天的缺点进行设计，同时为未来更智能的模型做计划。盲目重试和不验证工作是很好的例子。这些护栏几乎肯定会随着时间推移而消失，但要在今天构建健壮的智能体应用程序，它们是值得实验的有用工具。
|
||||
5. **为模型定制 Harness**。[Codex](https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide/) 和 [Claude](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) 提示指南显示模型需要不同的提示。使用 Claude Opus 4.6 的测试运行在早期 Harness 版本中得分 `59.6%`，有竞争力但比 Codex 差，因为他们没有与 Claude 运行相同的改进循环。许多原则可以推广，如良好的上下文准备和对验证的关注，但为你的任务运行几轮 Harness 迭代有助于跨任务最大化智能体性能。
|
||||
|
||||
在 Harness 设计中还有更多开放研究要做。有趣的途径包括多模型系统（Codex、Gemini 和 Claude 一起）、用于持续学习的记忆原语，以便智能体可以在任务上自主改进，以及跨模型测量 Harness 更改。
|
||||
|
||||
对于改进智能体的外层循环，LangChain 正在研究像 [RLMs](https://alexzhang13.github.io/blog/2025/rlm/) 这样的方法来更有效地挖掘追踪。他们将继续改进 Harness 并公开分享他们的研究。
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
- [[Long-Running-Harness-Design|长运行应用的 Harness 设计]]
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: "长运行应用的 Harness 设计"
|
||||
source: "Harness design for long-running application development"
|
||||
raw_sources:
|
||||
- path: raw/Harness design for long-running application development.md
|
||||
hash: "sha256:initial"
|
||||
tags:
|
||||
- "实践指南"
|
||||
- "Harness工程"
|
||||
- "多智能体"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 长运行应用的 Harness 设计
|
||||
|
||||
本文基于 Anthropic 团队的实践经验，探讨如何设计有效的 Harness 来支持长运行、自主的应用开发任务。
|
||||
|
||||
## 核心问题
|
||||
|
||||
在长运行 Agent 任务中，简单的实现通常会遇到两个持续存在的问题：
|
||||
|
||||
### 1. 上下文窗口填充导致的连贯性丧失
|
||||
|
||||
随着任务进行，模型往往会在冗长任务上失去连贯性。一些模型还表现出"**上下文焦虑**"——当它们接近认为的上下文限制时，会过早地结束工作。
|
||||
|
||||
**解决方案对比**：
|
||||
- **压缩 (Compaction)**：总结对话的早期部分，使同一个 Agent 可以在缩短的历史上继续。保留了连续性，但没有给 Agent 一个干净的状态。
|
||||
- **上下文重置 (Context Reset)**：完全清除上下文窗口并启动一个新的 Agent，结合结构化移交来携带前一个 Agent 的状态和下一步。提供了干净的状态，但增加了编排复杂性、令牌开销和延迟。
|
||||
|
||||
### 2. 自我评估问题
|
||||
|
||||
当被要求评估自己产生的工作时，Agent 往往会自信地赞扬工作——即使在人类观察者看来质量明显一般。对于像设计这样的主观任务，这个问题尤其明显。
|
||||
|
||||
**解决方案**：将执行工作的 Agent 与评判工作的 Agent 分离。调整独立的评估器使其持怀疑态度，比让生成器批评自己的工作要容易得多。
|
||||
|
||||
## 前端设计：使主观质量可评分
|
||||
|
||||
受生成对抗网络 (GANs) 的启发，设计了一个带有**生成器**和**评估器** Agent 的多 Agent 结构。
|
||||
|
||||
### 四个评分标准
|
||||
|
||||
1. **设计质量**：设计感觉像是一个连贯的整体而不是部分的集合吗？
|
||||
2. **原创性**：有自定义决策的证据吗，还是模板布局、库默认值和 AI 生成的模式？
|
||||
3. **工艺**：技术执行：排版层次结构、间距一致性、色彩和谐、对比度。
|
||||
4. **功能性**：独立于美学的可用性。
|
||||
|
||||
### 评估器校准
|
||||
|
||||
使用带有详细分数分解的少样本示例来校准评估器，确保评估器的判断与人类偏好一致，并减少迭代之间的分数漂移。
|
||||
|
||||
### 迭代循环
|
||||
|
||||
1. 生成器 Agent 首先根据用户提示创建 HTML/CSS/JS 前端
|
||||
2. 评估器使用 Playwright MCP 与实时页面交互
|
||||
3. 评估器对每个标准进行评分并编写详细的批评
|
||||
4. 反馈流回生成器作为下一次迭代的输入
|
||||
5. 每次生成运行 5 到 15 次迭代
|
||||
|
||||
## 扩展到全栈编码
|
||||
|
||||
将这种 GAN 启发的模式应用于全栈开发，生成器-评估器循环自然地映射到软件开发生命周期。
|
||||
|
||||
### 三 Agent 架构
|
||||
|
||||
**Planner (规划器)**：
|
||||
- 将简单的 1-4 句提示扩展为完整的产品规范
|
||||
- 被提示要对范围保持雄心勃勃
|
||||
- 专注于产品上下文和高级技术设计，而不是详细的技术实现
|
||||
- 寻找机会将 AI 功能编织到产品规范中
|
||||
|
||||
**Generator (生成器)**：
|
||||
- 一次从规范中提取一个功能
|
||||
- 每个冲刺使用 React、Vite、FastAPI 和 SQLite 堆栈实现应用
|
||||
- 被指示在每个冲刺结束时自我评估其工作，然后移交给 QA
|
||||
- 有 git 用于版本控制
|
||||
|
||||
**Evaluator (评估器)**：
|
||||
- 使用 Playwright MCP 像用户一样点击运行中的应用
|
||||
- 测试 UI 功能、API 端点和数据库状态
|
||||
- 根据发现的 bug 和一组标准对每个冲刺进行评分
|
||||
- 每个标准都有硬阈值，如果任何一个低于它，冲刺就失败
|
||||
|
||||
### 冲刺契约
|
||||
|
||||
在每个冲刺之前，生成器和评估器协商一个**冲刺契约**：在编写任何代码之前，就该工作块的"完成"是什么样子达成一致。
|
||||
|
||||
## 结果对比
|
||||
|
||||
### 复古游戏制作器示例
|
||||
|
||||
| Harness | 时长 | 成本 | 结果 |
|
||||
|---------|------|------|------|
|
||||
| 单独 Agent | 20 分钟 | $9 | 界面看起来符合预期，但实际游戏坏了，实体不响应输入 |
|
||||
| 完整 Harness | 6 小时 | $200 | 16 个功能规范，分布在十个冲刺中，包含精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及可分享链接的游戏导出 |
|
||||
|
||||
### 关键发现
|
||||
|
||||
- 单独运行的输出最初看起来令人印象深刻，但深入研究后问题开始出现
|
||||
- Harness 运行的应用立即显示出比单独运行更多的打磨和流畅性
|
||||
- 评估器使实现与规范保持一致，契约是细粒度的，评估器的发现足够具体，可以采取行动
|
||||
|
||||
## 简化 Harness
|
||||
|
||||
随着模型的改进，值得重新检查 Harness，剥离不再对性能有负载作用的部分，并添加新部分以实现以前不可能的更大能力。
|
||||
|
||||
### Opus 4.6 的改进
|
||||
|
||||
- 更仔细地规划
|
||||
- 更长时间地维持 Agent 任务
|
||||
- 可以在更大的代码库中更可靠地操作
|
||||
- 具有更好的代码审查和调试技能来发现自己的错误
|
||||
- 长上下文检索方面有了实质性改进
|
||||
|
||||
### 移除冲刺结构
|
||||
|
||||
保持规划器和评估器，因为每个都继续增加明显的价值。将评估器移动到运行结束时的单次通过，而不是每个冲刺评分。
|
||||
|
||||
### DAW 示例结果
|
||||
|
||||
使用更新的 Harness 生成数字音频工作站 (DAW)：
|
||||
|
||||
| Agent & Phase | 时长 | 成本 |
|
||||
|---------------|------|------|
|
||||
| Planner | 4.7 分钟 | $0.46 |
|
||||
| Build (Round 1) | 2 小时 7 分钟 | $71.08 |
|
||||
| QA (Round 1) | 8.8 分钟 | $3.24 |
|
||||
| Build (Round 2) | 1 小时 2 分钟 | $36.89 |
|
||||
| QA (Round 2) | 6.8 分钟 | $3.09 |
|
||||
| Build (Round 3) | 10.9 分钟 | $5.88 |
|
||||
| QA (Round 3) | 9.6 分钟 | $4.06 |
|
||||
| **总计 V2 Harness** | **3 小时 50 分钟** | **$124.70** |
|
||||
|
||||
## 经验教训
|
||||
|
||||
1. **实验**：与你正在构建的模型一起实验，阅读其在现实问题上的轨迹，并调整其性能以实现你想要的结果
|
||||
2. **分解**：在处理更复杂的任务时，有时可以通过分解任务并将专门的 Agent 应用于问题的每个方面来获得提升
|
||||
3. **重新检查**：当新模型落地时，通常很好的做法是重新检查 Harness，剥离不再对性能有负载作用的部分，并添加新部分以实现以前不可能的更大能力
|
||||
|
||||
> 随着模型的改进，有趣的 Harness 组合空间不会缩小。相反，它会移动，而 AI 工程师的有趣工作是继续找到下一个新颖的组合。
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: "Managed Agents：将大脑与手分离"
|
||||
source: "https://www.anthropic.com/engineering/managed-agents"
|
||||
author: "Anthropic"
|
||||
published: 2026
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- practices
|
||||
- managed-agents
|
||||
- anthropic
|
||||
raw_sources:
|
||||
- path: raw/Scaling Managed Agents Decoupling the brain from the hands.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# Managed Agents：将大脑与手分离
|
||||
|
||||
本文描述了 Anthropic 如何构建 Managed Agents——一个在 Claude 平台中代表你运行长 horizon 智能体的托管服务。核心思想是通过一组旨在超越任何特定实现的接口来虚拟化智能体的组件。
|
||||
|
||||
## 核心论点
|
||||
|
||||
工程博客上的一个持续主题是如何[构建有效的智能体](https://www.anthropic.com/engineering/building-effective-agents)和[为长运行工作设计 Harness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)。这项工作的一个共同线索是，Harness 编码了关于 Claude 自己不能做什么的假设。然而，这些假设需要经常被质疑，因为随着模型改进，它们可能会[过时](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)。
|
||||
|
||||
仅举一个例子，在先前的工作中[发现](https://www.anthropic.com/engineering/harness-design-long-running-apps)，Claude Sonnet 4.5 会在感知到其上下文限制临近时过早结束任务——一种有时称为"上下文焦虑"的行为。通过向 Harness 添加上下文重置来解决这个问题。但是当在 Claude Opus 4.5 上使用相同的 Harness 时，发现这种行为已经消失了。重置变成了死重。
|
||||
|
||||
期望 Harness 继续演进。因此构建了 Managed Agents：Claude 平台中的一个托管服务，通过一组旨在超越任何特定实现的接口——包括今天运行的那些——来代表你运行长 horizon 智能体。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 操作系统的启发
|
||||
|
||||
构建 Managed Agents 意味着解决计算中的一个老问题：如何为"尚未想到的程序"设计一个系统。几十年前，操作系统通过将硬件虚拟化为抽象——*进程、文件*——来解决这个问题，这些抽象足够通用，适用于尚不存在的程序。这些抽象比硬件更持久。`read()` 命令与它是访问 70 年代的磁盘组还是现代 SSD 无关。上面的抽象保持稳定，而下面的实现可以自由更改。
|
||||
|
||||
Managed Agents 遵循相同的模式。虚拟化了智能体的组件：会话（发生的一切的仅追加日志）、Harness（调用 Claude 并将 Claude 的工具调用路由到相关基础设施的循环）和沙箱（Claude 可以运行代码和编辑文件的执行环境）。这允许每个的实现被交换而不干扰其他的。对这些接口的形状有意见，但对它们后面运行的东西没有意见。
|
||||
|
||||
---
|
||||
|
||||
## 不要收养宠物
|
||||
|
||||
首先将所有智能体组件放入单个容器中，这意味着会话、智能体 Harness 和沙箱都共享一个环境。这种方法有好处，包括文件编辑是直接的系统调用，并且没有服务边界需要设计。
|
||||
|
||||
但是通过将所有东西耦合到一个容器中，遇到了一个老的基础设施问题：收养了一个[*宠物*](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/)。在宠物与牛的类比中，宠物是一个命名的、手工照料的个体，你不能失去它，而牛是可互换的。在他们的情况下，服务器变成了那个宠物；如果容器失败，会话就丢失了。如果容器没有响应，必须护理它恢复健康。
|
||||
|
||||
护理容器意味着调试无响应的卡住会话。唯一的窗口是 WebSocket 事件流，但这不能告诉我们*哪里*出现了故障，这意味着 Harness 中的错误、事件流中的数据包丢弃或容器脱机都呈现相同的情况。为了弄清楚出了什么问题，工程师必须在容器内打开一个 shell，但因为该容器通常也持有用户数据，这种方法基本上意味着缺乏调试能力。
|
||||
|
||||
第二个问题是，Harness 假设 Claude 处理的任何东西都与它一起生活在容器中。当客户要求将 Claude 连接到他们的虚拟私有云时，他们必须要么将他们的网络与我们的对等，要么在他们自己的环境中运行我们的 Harness。Harness 中烘焙的假设在想要将其连接到不同的基础设施时变成了一个问题。
|
||||
|
||||
---
|
||||
|
||||
## 将大脑与手分离
|
||||
|
||||
到达的解决方案是将"大脑"（Claude 及其 Harness）与"手"（执行操作的沙箱和工具）和"会话"（会话事件的日志）两者分离。每个都成为一个对其他组件做出很少假设的接口，并且每个都可以独立失败或被替换。
|
||||
|
||||
**Harness 离开容器。** 将大脑与手分离意味着 Harness 不再生活在容器内。它像调用任何其他工具一样调用容器：`execute(name, input) → string`。容器变成了牛。如果容器死亡，Harness 将失败捕获为工具调用错误并将其传递回 Claude。如果 Claude 决定重试，可以使用标准配方重新初始化一个新容器：`provision({resources})`。不再需要护理失败的容器恢复健康。
|
||||
|
||||
**从 Harness 失败中恢复。** Harness 也变成了牛。因为会话日志位于 Harness 之外，Harness 中没有任何东西需要在崩溃后幸存。当一个失败时，可以用 `wake(sessionId)` 重新启动一个新的，使用 `getSession(id)` 取回事件日志，并从最后一个事件恢复。在智能体循环期间，Harness 使用 `emitEvent(id, event)` 写入会话，以保持事件的持久记录。
|
||||
|
||||
|
||||
|
||||
**安全边界。** 在耦合设计中，Claude 生成的任何不受信任的代码都在与凭证相同的容器中运行——因此提示注入只需要说服 Claude 读取自己的环境。一旦攻击者拥有这些令牌，他们就可以生成新的、不受限制的会话并将工作委托给它们。狭窄的范围是一个明显的缓解措施，但这编码了关于 Claude 不能用有限令牌做什么的假设——而 Claude 正变得越来越智能。结构性修复是确保令牌永远无法从 Claude 生成代码运行的沙箱访问到。
|
||||
|
||||
使用两种模式来确保这一点。Auth 可以与资源捆绑在一起，也可以保存在沙箱外的保险库中。对于 Git，使用每个存储库的访问令牌在沙箱初始化期间克隆存储库并将其连接到本地 git remote。Git `push` 和 `pull` 可以从沙箱内部工作，而智能体永远不会自己处理令牌。对于自定义工具，支持 MCP 并将 OAuth 令牌存储在安全保险库中。Claude 通过专用代理调用 MCP 工具；这个代理接受与会话关联的令牌。然后代理可以从保险库获取相应的凭证并调用外部服务。Harness 永远不会知道任何凭证。
|
||||
|
||||
---
|
||||
|
||||
## 会话不是 Claude 的上下文窗口
|
||||
|
||||
长 horizon 任务通常超过 Claude 上下文窗口的长度，解决这个问题的标准方法都涉及关于保留什么的不可逆决策。在关于上下文工程的[先前工作](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)中探索了这些技术。例如，压缩让 Claude 保存其上下文窗口的摘要，记忆工具让 Claude 将上下文写入文件，从而实现跨会话学习。这可以与上下文修剪配对，上下文修剪选择性地删除令牌，如旧工具结果或思考块。
|
||||
|
||||
但是选择性保留或丢弃上下文的不可逆决策可能导致失败。很难知道未来回合将需要哪些令牌。如果消息被压缩步骤转换，Harness 会从 Claude 的上下文窗口中删除压缩的消息，并且只有在存储时才能恢复这些消息。先前的工作[已经探索](https://arxiv.org/pdf/2512.24601)通过将上下文存储为生活在*上下文窗口之外*的对象来解决这个问题的方法。例如，上下文可以是 REPL 中的一个对象，LLM 通过编写代码来过滤或切片它来以编程方式访问它。
|
||||
|
||||
|
||||
|
||||
在 Managed Agents 中，会话提供了相同的好处，充当生活在 Claude 上下文窗口之外的上下文对象。但不是存储在沙箱或 REPL 中，上下文被持久存储在会话日志中。接口 `getEvents()` 允许大脑通过选择事件流的位置切片来询问上下文。该接口可以灵活使用，允许大脑从上次停止阅读的地方继续，倒回到特定时刻之前的几个事件以查看前导，或在特定操作之前重新阅读上下文。
|
||||
|
||||
任何获取的事件也可以在传递给 Claude 的上下文窗口之前在 Harness 中进行转换。这些转换可以是 Harness 编码的任何东西，包括上下文组织以实现高提示缓存命中率和上下文工程。分离了会话中可恢复的上下文存储和 Harness 中任意上下文管理的关注点，因为无法预测未来模型将需要什么特定的上下文工程。接口将该上下文管理推送到 Harness 中，并且只保证会话是持久的并且可用于询问。
|
||||
|
||||
---
|
||||
|
||||
## 多大脑，多手
|
||||
|
||||
**多大脑。** 将大脑与手分离解决了最早的客户投诉之一。当团队希望 Claude 针对他们自己 VPC 中的资源工作时，唯一的路径是将他们的网络与我们的对等，因为持有 Harness 的容器假设每个资源都在它旁边。一旦 Harness 不再在容器中，那个假设就消失了。相同的更改带来了性能回报。当最初将大脑放在容器中时，意味着许多大脑需要同样多的容器。对于每个大脑，在该容器被配置之前不能进行推理；每个会话都预先支付完整的容器设置成本。每个会话，即使是那些永远不会接触沙箱的会话，都必须克隆存储库、启动进程、从我们的服务器获取待处理事件。
|
||||
|
||||
那段死时间表示为首次 token 时间（TTFT），它衡量会话在接受工作和产生其第一个响应令牌之间等待的时间。TTFT 是用户最敏锐地*感受到*的延迟。
|
||||
|
||||
将大脑与手分离意味着容器仅在需要时才由大脑通过工具调用 `(execute(name, input) → string)` 来配置。因此，不需要立即容器的会话不必等待一个。一旦编排层从会话日志中提取待处理事件，推理就可以开始。使用这种架构，p50 TTFT 下降了大约 60%，p95 下降了超过 90%。扩展到许多大脑只意味着启动许多无状态 Harness，并且仅在需要时将它们连接到手。
|
||||
|
||||
**多手。** 还希望能够将每个大脑连接到多只手。在实践中，这意味着 Claude 必须推理许多执行环境并决定在哪里发送工作——这比在单个 shell 中操作更难的认知任务。从单个容器中的大脑开始，因为早期的模型没有能力做到这一点。随着智能的扩展，单个容器变成了限制而不是：当该容器失败时，失去了大脑正在伸向的每只手的状态。
|
||||
|
||||
将大脑与手分离使每只手成为一个工具，`execute(name, input) → string`：一个名称和输入进去，一个字符串返回。该接口支持任何自定义工具、任何 MCP 服务器和我们自己的工具。Harness 不知道沙箱是容器、电话还是 Pokémon 模拟器。并且因为没有手耦合到任何大脑，大脑可以将手彼此传递。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 结论
|
||||
|
||||
面临的挑战是一个老问题：如何为"尚未想到的程序"设计一个系统。操作系统通过将硬件虚拟化为足够通用的抽象，适用于尚不存在的程序，已经持续了几十年。使用 Managed Agents，旨在设计一个适应 Claude 周围未来 Harness、沙箱或其他组件的系统。
|
||||
|
||||
Managed Agents 是一个具有相同精神的元 Harness，对 Claude 未来将需要的*特定*Harness 没有意见。相反，它是一个具有允许许多不同 Harness 的通用接口的系统。例如，Claude Code 是一个在任务中广泛使用的优秀 Harness。还表明特定任务的智能体 Harness 在狭窄领域表现出色。Managed Agents 可以容纳其中任何一个，随着时间推移匹配 Claude 的智能。
|
||||
|
||||
元 Harness 设计意味着对 Claude 周围的接口有意见：期望 Claude 将需要操纵状态（会话）和执行计算（沙箱）的能力。还期望 Claude 将需要扩展到多大脑和多手的能力。设计了接口，以便这些可以在长时间范围内可靠且安全地运行。但对 Claude 将需要的大脑或手的数量或位置没有做出任何假设。
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Long-Running-Harness-Design|长运行应用的 Harness 设计]]
|
||||
@@ -0,0 +1,221 @@
|
||||
---
|
||||
title: "MiniMax M2.7：开启模型的自我进化"
|
||||
source: "https://www.minimaxi.com/news/minimax-m27-zh"
|
||||
author: "MiniMax"
|
||||
published: 2026-04-11
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- practices
|
||||
- model-evolution
|
||||
- minimax
|
||||
raw_sources:
|
||||
- path: raw/MiniMax M2.7 开启模型的自我进化.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# MiniMax M2.7：开启模型的自我进化
|
||||
|
||||
本文介绍了 MiniMax M2.7——第一个模型深度参与迭代自己的模型。M2.7 能够自行构建复杂 Agent Harness，并基于 Agent Teams、复杂 Skills、Tool Search Tool 等能力，完成高度复杂的生产力任务。
|
||||
|
||||
## 核心亮点
|
||||
|
||||
在 M2 系列模型发布后的几个月，MiniMax 收到了大量热心用户的反馈和建议，这促使他们进一步加速模型的迭代效率。除了更加认真工作之外，能找到的唯一途径就是**开启模型和组织的自我进化**。
|
||||
|
||||
**关键声明**：MiniMax M2.7 是第一个模型深度参与迭代自己的模型。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 三大核心能力
|
||||
|
||||
### 1. 真实软件工程能力
|
||||
|
||||
M2.7 在真实的软件工程中有优异的表现，包括端到端的完整项目交付，分析日志排查 Bug、代码安全，机器学习等。
|
||||
|
||||
**基准测试成绩**：
|
||||
- **SWE-Pro**：56.22%，几乎接近 Opus 最好的水平
|
||||
- **VIBE-Pro**：55.6%（端到端完整项目交付场景）
|
||||
- **Terminal Bench 2**：57.0%（对复杂工程系统的深层理解）
|
||||
- **SWE Multilingual**：76.5
|
||||
- **Multi SWE Bench**：52.7
|
||||
|
||||
这一能力延伸到了端到端的完整项目交付场景——无论是 Web、Android、iOS 还是 Simulation 类需求，都可以直接交给 M2.7 完成。
|
||||
|
||||
**线上生产环境故障调试示例**：
|
||||
面对实际的生产环境告警，M2.7 能：
|
||||
- 关联监控指标与部署时间线做因果推理
|
||||
- 对轨迹采样做统计分析并提出精准假设
|
||||
- 主动连接数据库执行验证根因
|
||||
- 定位到代码仓库中缺失的索引迁移文件
|
||||
- 知道用非阻塞建索引先止血，再提 MR
|
||||
|
||||
> **结果**：从可观测性分析、数据库专业知识到 SRE 级别的决策判断——这不只是一个会写代码的模型，而是一个真正理解生产系统的模型。相比传统的人工排障流程，基于 M2.7，已多次将线上生产系统故障的恢复时间缩短到三分钟以内。
|
||||
|
||||
**原生 Agent Teams 能力**：
|
||||
Agent Teams 对模型提出了范式级要求：角色边界、对抗性推理、协议遵循、行为分化——这些无法通过提示词，必须内化为模型的原生能力。Agent Teams 场景下，模型需要稳定锚定角色身份、主动挑战队友的逻辑与伦理盲区、在复杂状态机中自主决策。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 2. 专业办公能力
|
||||
|
||||
在专业办公领域，提升了模型在各领域的专业知识和任务交付能力。
|
||||
|
||||
**基准测试成绩**：
|
||||
- **GDPval-AA**：ELO 得分 1495-1500，为开源最高，仅次于 Opus 4.6、Sonnet 4.6 和 GPT5.4，超过了 GPT5.3
|
||||
- **Toolathon**：46.3% 正确率，达到全球第一梯队水平
|
||||
- **MM Claw**：62.7% 正确率，接近最新的 Sonnet 4.6
|
||||
|
||||
**核心办公能力**：
|
||||
1. **专业知识与任务交付能力** - 模型需要具备各领域的专业知识，理解用户的需求
|
||||
2. **与复杂环境的交互能力** - 泛化的日常场景意味着模型需要灵活适应各类上下文、调用各种 skills 和工具、并在长程交互中保持稳定的指令遵循
|
||||
|
||||
**Office 套件能力**：
|
||||
- 对 Office 三件套 Excel/PPT/Word 的复杂编辑能力显著提升
|
||||
- 能更好地完成多轮修改和高保真的编辑
|
||||
- 既能够基于模版和 skills 直接生成文件，也能够遵从用户的交互指令，对已有的文件做多轮的高保真编辑
|
||||
- 在 40 个复杂 skills (> 2000 Token) 的 case 上，仍能保持 97% 的 skills 遵循率
|
||||
|
||||
**Finance 领域示例**：
|
||||
在阅读研报并建模公司未来营收的场景，M2.7 可以：
|
||||
- 自主阅读公司的年报与业绩沟通会纪要
|
||||
- 交叉比对多篇研报
|
||||
- 独立设计假设并构建营收预测模型
|
||||
- 再基于模版产出 PPT 和研究报告
|
||||
|
||||
从业者的评价是：产出物已经可以作为初稿直接进入后续工作流程。
|
||||
|
||||
---
|
||||
|
||||
### 3. 互动娱乐能力
|
||||
|
||||
M2.7 具备优秀的身份保持能力和情商，除了生产力使用外，给互动娱乐场景的创新也准备了空间。
|
||||
|
||||
在 OpenClaw 等 Agent 脚手架的使用过程中，不少用户在使用 Agent 完成工作的同时，还希望模型具备比较高的情商和复杂人设保持能力。在有人设的情况下，用户不再只是让模型机械完成任务，而是开始自然于与 Agent"相处"。
|
||||
|
||||
这促使 MiniMax 思考，产品与交互设计、内容创作、甚至娱乐体验的构建，都可以被 AI 原生驱动的可能性。这会让 Agentic 模型的使用从单纯的生产力能进一步拓展到互动娱乐。
|
||||
|
||||
**OpenRoom：Agent 交互系统**
|
||||
基于此，MiniMax 构建了一个 Agent 交互系统 OpenRoom，它将 AI 互动置入一个万物皆可互动的 Web GUI 空间。在这里：
|
||||
- 对话即驱动，实时产生视觉反馈与场景交互
|
||||
- 角色可以主动地与环境交互
|
||||
- 框架扩展性较高，能够随着模型 Agentic 能力的提升和社区的共建持续进化
|
||||
- 探索出更多人与 Agent 之间全新的交互方式
|
||||
|
||||
**开源信息**：
|
||||
- 项目地址：[github.com/MiniMax-AI/OpenRoom](https://github.com/MiniMax-AI/OpenRoom)
|
||||
- 立即体验：[openroom.ai](https://openroom.ai/)
|
||||
- 代码大部分也是 AI 写的
|
||||
|
||||
---
|
||||
|
||||
## 模型自我进化智能体
|
||||
|
||||
MiniMax 分享了一个内部让 M2 系列模型自我进化的实践，这也是对模型 Agent 能力边界的探索。
|
||||
|
||||
### 研究型 Agent Harness
|
||||
|
||||
Agent Harness 通常依赖复杂的 Skills、记忆系统和其他组件来提升模型对不同工作环境的适应能力。在此基础上，MiniMax 在 M2 的早期版本中，将其引导为一个**研究型 Agent Harness**——它能够与不同的研究项目组进行交互和协作。
|
||||
|
||||
**系统覆盖**：
|
||||
- 数据流水线
|
||||
- 训练环境
|
||||
- 评测基础设施
|
||||
- 跨团队协作
|
||||
- 持久化记忆
|
||||
|
||||
让研究员可以驱动它来交付更好的模型。研究 Agent 驱动着产出下一代模型的迭代循环。研究员在每一层引导方向，模型在每一层负责构建。
|
||||
|
||||
### RL 场景示例
|
||||
|
||||
以一个 RL 场景为例：
|
||||
1. 研究员从一个实验想法出发，与 Agent 展开讨论
|
||||
2. Agent 协助进行文献调研，持续跟踪预设的实验规格，完成数据流水线及其他对接工作，并启动实验
|
||||
3. 实验运行期间，它会自动监控和分析实验状态，并自动触发日志读取、问题排查、指标分析、代码修复、合并请求以及冒烟测试
|
||||
4. 识别并配置那些细微但关键的变更
|
||||
|
||||
这些工作过去可能需要来自不同团队的多位同事协作完成，而现在研究员只需在关键决策和讨论时介入。这大幅加速了问题发现和实验迭代，从而更快地交付模型。
|
||||
|
||||
**结果**：在这个场景下，M2.7 能够胜任 30-50% 的工作流。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Harness 自我进化
|
||||
|
||||
MiniMax 在迭代过程中也意识到，**模型自主迭代 harness 的能力也至关重要**。
|
||||
|
||||
内部的 harness 会：
|
||||
- 自主收集反馈
|
||||
- 建立内部任务的评测集
|
||||
- 基于此不断迭代自己的 Agent 架构、Skills/MCP 实现和记忆机制
|
||||
- 更好和更高效的完成任务
|
||||
|
||||
### 内部脚手架优化示例
|
||||
|
||||
让 M2.7 优化一个内部脚手架上模型的软件工程开发表现。M2.7 全程自主运行，执行以下迭代循环超过 100 轮：
|
||||
|
||||
```
|
||||
分析失败轨迹 → 规划改动 → 修改脚手架代码 → 运行评测 → 对比结果 → 决定保留或回退
|
||||
```
|
||||
|
||||
**M2.7 发现的有效优化**：
|
||||
- 系统性搜索温度、频率惩罚、存在惩罚等采样参数的最优组合
|
||||
- 为模型设计更具体的工作流指引（如修复后自动搜索其他文件中的相同 bug 模式）
|
||||
- 在脚手架的 Agent Loop 中添加循环检测等优化
|
||||
|
||||
**最终结果**：在内部评测集上效果提升 30%。
|
||||
|
||||
---
|
||||
|
||||
## MLE Bench Lite 测试
|
||||
|
||||
MiniMax 相信，未来的 AI 自我进化会逐步向完全自动化过渡，包括完全自主的协调数据构建、模型训练、推理架构、评测等等。
|
||||
|
||||
**测试设置**：
|
||||
- 用 M2.7 参与了 MLE Bench Lite 的 22 个机器学习任务测试
|
||||
- 几乎囊括了研发的所有环节
|
||||
- 设计和实现了一个简易的脚手架来引导 Agent 进行自主优化
|
||||
- 核心模块包括：短时记忆、自反馈以及自优化三个模块
|
||||
- 总共测试三次，每次有 24 小时来迭代进化
|
||||
|
||||
**具体运作方式**：
|
||||
- Agent 完成每轮迭代后会形成一个短时记忆文件
|
||||
- 同时对当前轮次的结果进行自反馈，从而给下一轮次提供潜在的优化方向
|
||||
- 下一轮次基于所有历史轮次的记忆及自反馈链进行下一步的自优化
|
||||
|
||||
**成绩**：
|
||||
- 最好的一次取得 9 枚金牌，5 枚银牌，1 枚铜牌
|
||||
- 三次平均是 66.6% 的得牌率
|
||||
- 此成绩仅次于：
|
||||
- Opus-4.6 (75.7%)
|
||||
- GPT-5.4 (71.2%)
|
||||
- 和 Gemini-3.1 (66.6%) 持平
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 组织进化
|
||||
|
||||
基于上述能力，M2.7 也在显著加速 MiniMax 自身向一个 AI Native 组织的进化。
|
||||
|
||||
|
||||
|
||||
**产品可用性**：
|
||||
- MiniMax M2.7 已在 MiniMax Agent 与开放平台上全量上线
|
||||
- MiniMax Agent：[agent.minimaxi.com](https://agent.minimaxi.com/)
|
||||
- API 服务：[platform.minimaxi.com](https://platform.minimaxi.com/)
|
||||
- Coding Plan 订阅：[platform.minimaxi.com/subscribe/coding-plan](https://platform.minimaxi.com/subscribe/coding-plan)
|
||||
|
||||
> **Intelligence with Everyone.**
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Meta-Harness|元 Harness]]
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
title: "Mitchell Hashimoto 的 AI 采用之旅"
|
||||
source: "https://mitchellh.com/writing/my-ai-adoption-journey"
|
||||
author: "Mitchell Hashimoto"
|
||||
published: 2026-02-05
|
||||
last_updated: 2026-04-11
|
||||
tags:
|
||||
- practices
|
||||
- adoption
|
||||
- harness-engineering
|
||||
raw_sources:
|
||||
- path: raw/My AI Adoption Journey.md
|
||||
hash: "sha256:initial"
|
||||
---
|
||||
|
||||
# Mitchell Hashimoto 的 AI 采用之旅
|
||||
|
||||
本文记录了 HashiCorp 创始人 Mitchell Hashimoto 从 AI 怀疑论者到深度用户的六个阶段采用之旅。他的经历为如何有效采用 AI 工具提供了实用的指导框架。
|
||||
|
||||
## 核心论点
|
||||
|
||||
Mitchell 认为，任何有意义的工具采用都必然经历三个阶段：
|
||||
|
||||
1. **低效期** - 初期感觉不如现有工作流高效
|
||||
2. **胜任期** - 逐渐掌握，达到与手动工作相当的效率
|
||||
3. **变革期** - 发现新的工作方式，彻底改变工作流和生活
|
||||
|
||||
> **关键洞察**：必须强迫自己度过前两个阶段，才能发现 AI 的真正价值。
|
||||
|
||||
---
|
||||
|
||||
## 六个采用阶段
|
||||
|
||||
### 阶段 1：放弃聊天机器人界面
|
||||
|
||||
**立即停止尝试通过聊天机器人执行有意义的工作。**
|
||||
|
||||
聊天机器人（如 ChatGPT、Gemini 网页版）有其实际价值，是日常 AI 工作流的一部分，但在编码方面的效用非常有限。你大多只是希望它们基于先前训练得出正确结果，而纠正它们需要你（人类）反复告诉它们错了。这种方式效率低下。
|
||||
|
||||
**关键发现**：
|
||||
- 聊天界面在棕色地带（brownfield）项目中效果很差
|
||||
- 复制粘贴代码和命令输出的过程令人沮丧
|
||||
- 必须使用**智能体（Agent）**才能找到价值
|
||||
|
||||
**智能体的最低要求**：
|
||||
- 读取文件
|
||||
- 执行程序
|
||||
- 发出 HTTP 请求
|
||||
|
||||
> **个人转折点**：将 Zed 命令面板的截图粘贴到 Gemini，要求它用 SwiftUI 重现，结果非常好。Ghostty 的 macOS 命令面板仅在此基础上做了轻微修改。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 2：重现自己的工作
|
||||
|
||||
**强迫自己用智能体重现所有手动提交。**
|
||||
|
||||
Mitchell 最初使用 Claude Code 时并不满意，觉得必须润色它生成的所有内容，这比自己动手花的时间还多。但他没有放弃，而是**强迫自己用智能体重现所有手动提交**—— literally 把工作做两遍。先手动完成工作，然后与智能体斗争以产生相同质量和功能的结果（当然不让它看到手动解决方案）。
|
||||
|
||||
**这一过程的收获**：
|
||||
1. **分解任务** - 将会话拆分为独立、清晰、可操作的任务。不要试图在一个大型会话中"画出整只猫头鹰"。
|
||||
2. **规划与执行分离** - 对于模糊的请求，将工作分为规划会话和执行会话。
|
||||
3. **自我验证** - 如果给智能体一种验证其工作的方法，它通常会修正自己的错误并防止回归。
|
||||
|
||||
**更重要的收获**：
|
||||
- 了解了智能体擅长什么、不擅长什么
|
||||
- 对于擅长的任务，掌握了如何获得想要的结果
|
||||
- 知道了**什么时候不应该使用智能体**——这本身就是巨大的时间节省
|
||||
|
||||
---
|
||||
|
||||
### 阶段 3：日终智能体
|
||||
|
||||
**每天最后 30 分钟启动一个或多个智能体。**
|
||||
|
||||
Mitchell 的下一个模式是：**留出每天最后 30 分钟来启动一个或多个智能体。** 他的假设是，也许可以让智能体在他无法工作的时间取得一些积极进展。基本上：不要试图在已有时间内做更多事情，而是尝试在没有的时间内做更多事情。
|
||||
|
||||
**发现的高价值任务类别**：
|
||||
- **深度研究会话** - 要求智能体调查某个领域，例如查找特定语言中具有特定许可证类型的所有库，并为每个库生成多页摘要，包括优缺点、开发活动、社会情绪等。
|
||||
- **并行智能体尝试不同的模糊想法** - 不期望它们产生可交付的成果，但也许可以在第二天处理任务时揭示一些未知的未知。
|
||||
- **Issue 和 PR 分类/审查** - 智能体擅长使用 `gh`（GitHub CLI），因此手动编写了一个快速方法来并行启动一堆智能体来分类问题。不允许智能体回应，只需要第二天的报告来指导高价值或低工作量的任务。
|
||||
|
||||
> **关键洞察**：这不是让智能体整夜循环运行。大多数情况下，智能体在半小时内完成任务。但在工作日的后半段，通常会感到疲惫，脱离心流状态，个人效率低下，因此将精力转移到启动这些智能体上，第二天早上可以"热启动"，比平时更快地开始工作。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 4：外包确定的任务
|
||||
|
||||
**让智能体做所有它几乎肯定能正确完成的工作，同时你处理其他任务。**
|
||||
|
||||
到了这个阶段，Mitchell 对 AI 擅长和不擅长的任务非常有信心。对某些任务，AI 会取得基本正确的解决方案有很高的信心。因此，旅程的下一步是：**让智能体做所有这些工作，同时你处理其他任务。**
|
||||
|
||||
**具体做法**：
|
||||
- 每天从昨晚分类智能体的结果开始
|
||||
- 手动过滤出智能体几乎肯定能很好解决的问题
|
||||
- 让它们在后台运行（一次一个，不是并行）
|
||||
- **同时处理其他事情**——不是刷社交媒体，而是处于正常的、AI 前的深度思考模式
|
||||
|
||||
**关键规则**：
|
||||
- **关闭智能体桌面通知** - 上下文切换非常昂贵。为了保持效率，人类应该控制何时中断智能体，而不是相反。
|
||||
- 在工作的自然休息时间，切换过去检查一下，然后继续。
|
||||
|
||||
> **技能形成的权衡**：这很好地抵消了 [Anthropic 技能形成论文](https://www.anthropic.com/research/AI-assistance-coding-skills) 中提出的问题。你在权衡：不为委托给智能体的任务形成技能，同时继续在手动处理的任务中自然形成技能。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 5：工程化 Harness
|
||||
|
||||
**每次发现智能体犯错时，花时间设计一个解决方案，让智能体永远不会再犯那个错误。**
|
||||
|
||||
> **显而易见的事实**：当智能体第一次就产生正确结果，或最坏情况下只需要最少润色时，效率会高得多。实现这一点的最可靠方法是给智能体快速、高质量的工具来自动告诉它什么时候错了。
|
||||
|
||||
**Harness 工程的两种形式**：
|
||||
|
||||
1. **更好的隐式提示（AGENTS.md）** - 对于简单的事情，比如智能体反复运行错误的命令或找到错误的 API，更新 `AGENTS.md`（或等效文件）。每一行都基于一个糟糕的智能体行为，而且几乎完全解决了所有问题。
|
||||
|
||||
2. **实际的编程工具** - 例如，截图脚本、运行筛选测试等。这通常与 AGENTS.md 更改配对，让它知道这个工具的存在。
|
||||
|
||||
> **这就是我今天的位置**：每当看到智能体做了坏事，就真诚地努力防止它再做那件坏事。或者，相反地，真诚地努力让智能体验证它们在做正确的事。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 6：始终有一个智能体在运行
|
||||
|
||||
**如果智能体没有在运行，问问自己"现在有什么是智能体可以为我做的吗？"**
|
||||
|
||||
Mitchell 同时也在**始终有一个智能体在运行**的目标下运作。他特别喜欢将这与较慢、更周到的模型（如 Amp 的深度模式，本质上就是 GPT-5.2-Codex）结合使用，这些模型可能需要 30 多分钟来进行小的更改。但另一面是，它确实倾向于产生非常好的结果。
|
||||
|
||||
**当前状态**：
|
||||
- 还没有运行多个智能体，目前也不想这么做
|
||||
- 有一个智能体在运行是一个很好的平衡
|
||||
- 目前正常工作日中可能只有 10-20% 的时间有效地让后台智能体运行
|
||||
- 正在积极努力改善这一点
|
||||
|
||||
> **关键原则**：不想为了运行智能体而运行智能体。只有当有一个认为对自己真正有帮助的任务时才运行它们。这个目标的一部分挑战是改善自己的工作流和工具，以便可以有源源不断的高质量工作来委托。即使没有 AI，这也很重要！
|
||||
|
||||
---
|
||||
|
||||
## 今天的状态
|
||||
|
||||
这就是 Mitchell 今天的位置。
|
||||
|
||||
通过这段旅程，他个人达到了一个点：成功使用现代 AI 工具，并相信自己以基于现实的适当、审慎的观点来处理它。他完全不在乎 AI 是否会留下来——他是一个软件工匠，只是出于对这个行业的热爱而构建东西。
|
||||
|
||||
整个领域发展得如此之快，他确信很快就会回头看这篇文章，嘲笑自己的天真。但正如他们所说，如果你不能为过去的自己感到尴尬，你可能就没有成长。只希望能朝着正确的方向成长！
|
||||
|
||||
---
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Long-Running-Harness-Design|长运行应用的 Harness 设计]]
|
||||
- [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]
|
||||
@@ -1,150 +0,0 @@
|
||||
---
|
||||
title: Mitchellh AI 采用之旅
|
||||
tags: [实践指南, 采用路径, 个人工作流]
|
||||
source: [Mitchell Hashimoto]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# Mitchellh AI 采用之旅
|
||||
|
||||
本文总结了 HashiCorp 创始人 Mitchell Hashimoto 的个人 AI 工具采用历程。他分享了从怀疑论者到深度用户的六个阶段，为其他开发者提供了实用的参考路径。
|
||||
|
||||
## 核心观点
|
||||
|
||||
> "我采用任何有意义的工具的经验是，我必然经历三个阶段：(1) 低效率时期 (2) 胜任时期，最后 (3) 工作流和生活改变发现时期。"
|
||||
|
||||
---
|
||||
|
||||
## 六个阶段
|
||||
|
||||
### 阶段 1：放弃聊天机器人
|
||||
|
||||
**立即停止尝试通过聊天机器人执行有意义的工作**（例如 ChatGPT、网页版 Gemini 等）。
|
||||
|
||||
聊天机器人确实有价值，而且是 Mitchell AI 工作流的日常组成部分，但它们在编码中的效用非常有限，因为你大多希望它们根据先前训练得出正确结果，而纠正它们涉及人类（你）反复告诉它们错了。这是低效的。
|
||||
|
||||
**关键点：**
|
||||
- 每个人的第一次 AI 体验都是聊天界面
|
||||
- 每个人第一次尝试用 AI 编码都是要求聊天界面写代码
|
||||
- 要找到价值，你**必须**使用**智能体**（Agent）
|
||||
|
||||
**什么是智能体？**
|
||||
智能体是行业采用的术语，指能够聊天并循环调用外部行为的 LLM。至少，智能体必须具备以下能力：
|
||||
- 读取文件
|
||||
- 执行程序
|
||||
- 发起 HTTP 请求
|
||||
|
||||
---
|
||||
|
||||
### 阶段 2：重现你自己的工作
|
||||
|
||||
Mitchell 最初尝试 Claude Code 时并没有留下深刻印象。他只是没有从会话中得到好的结果。他觉得必须润色它生成的所有内容，这个过程比他自己做要花更多时间。
|
||||
|
||||
**解决方案：**
|
||||
> "我没有放弃，而是**强迫自己用智能体重现所有手动提交**。我真的做了两次工作。我会手动完成工作，然后与智能体斗争以产生相同的质量和功能结果（当然，不让它看到我的手动解决方案）。"
|
||||
|
||||
**这是痛苦的**，因为它妨碍了简单地完成事情。但 Mitchell 从第一性原理中自己发现了别人已经在说的东西，但自己发现它产生了更强的基本理解：
|
||||
|
||||
1. 将会话分解为单独清晰、可操作的任务。不要试图在一个大型会话中"画猫头鹰"。
|
||||
2. 对于模糊的请求，将工作分成单独的规划与会话。
|
||||
3. 如果你给智能体验证其工作的方法，它往往会修复自己的错误并防止回归。
|
||||
|
||||
更一般地说，他还发现了智能体当时擅长什么、不擅长什么的边界，以及对于它们擅长的任务如何实现想要的结果。
|
||||
|
||||
所有这些都导致了显著的效率提升，以至于他开始自然地使用智能体，感觉不比自己做慢（但他仍然不觉得更快，因为他主要在照看智能体）。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 3：日终智能体
|
||||
|
||||
为了尝试找到一些效率，Mitchell 开始了一个新模式：**每天划出最后 30 分钟来启动一个或多个智能体。**
|
||||
|
||||
他的假设是，如果智能体能在他无论如何都不能工作的时间里取得一些**积极进展**，也许他可以获得一些效率。基本上：与其试图在他拥有的时间里做更多，不如尝试在他没有的时间里做更多。
|
||||
|
||||
**发现的有价值的工作类别：**
|
||||
|
||||
1. **深度研究会话**：要求智能体调查某个领域，例如查找特定许可证类型的特定语言的所有库，并为每个库生成关于其优缺点、开发活动、社会情绪等的多页摘要。
|
||||
|
||||
2. **并行智能体尝试他没有时间开始的不同模糊想法**：不期望它们产生他会交付的东西，但也许可以在第二天他处理任务时阐明一些未知的未知。
|
||||
|
||||
3. **问题和 PR 分类/审查**：智能体擅长使用 `gh`（GitHub CLI），因此手动编写了一个快速方法来并行启动一堆来分类问题。不会允许智能体回复，只想要第二天的报告来尝试引导他走向高价值或低工作量的任务。
|
||||
|
||||
**结果：**
|
||||
他开始感觉自己比 AI 之前做的更多，哪怕只是一点点。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 4：外包稳操胜券的任务
|
||||
|
||||
到了这个阶段，Mitchell 对他的 AI 擅长和不擅长什么任务非常有信心。他对某些任务 AI 会实现基本正确的解决方案有非常高的信心。
|
||||
|
||||
**所以旅程的下一步是：让智能体做所有这些工作，而他做其他任务。**
|
||||
|
||||
更具体地说：
|
||||
- 每天从查看前一晚分类智能体的结果开始
|
||||
- 手动过滤以找到智能体几乎肯定会很好解决的问题
|
||||
- 让它们在后台继续（一次一个，不是并行）
|
||||
|
||||
**同时，他做其他事情。** 不是去社交媒体（比平时不用 AI 更多），不是看视频等。他处于自己的、正常的、AI 之前的深度思考模式，处理他想做或必须做的事情。
|
||||
|
||||
**非常重要：关闭智能体桌面通知。** 上下文切换非常昂贵。为了保持效率，他发现作为人类控制何时中断智能体是他的工作，而不是相反。不要让智能体通知你。在工作的自然休息时间，切换标签检查它，然后继续。
|
||||
|
||||
**结果：**
|
||||
他坚定地处于"我无法回去"的境地。他觉得更有效率，但即使不是，他最喜欢的是他现在可以将编码和思考集中在他真正喜欢的任务上，同时仍然充分完成他不喜欢的任务。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 5：设计 Harness
|
||||
|
||||
冒着陈述显而易见的风险：智能体在第一次产生正确结果时效率要高得多，或者最坏情况下产生需要最少润色的结果。实现这一点的最可靠方法是给智能体快速、高质量的工具来自动告诉它什么时候错了。
|
||||
|
||||
Mitchell 不知道是否有一个广泛的行业接受的术语，但他已经逐渐称之为"**Harness 工程**"。这是这样一种想法：任何时候你发现智能体犯了错误，你都花时间设计一个解决方案，使智能体永远不会再犯那个错误。
|
||||
|
||||
**这有两种形式：**
|
||||
|
||||
1. **更好的隐式提示（AGENTS.md）**：对于简单的事情，比如智能体反复运行错误的命令或找到错误的 API，更新 `AGENTS.md`（或等效文件）。每一行都是基于坏的智能体行为，并且几乎完全解决了所有问题。
|
||||
|
||||
2. **实际的编程工具**：例如，截图脚本、运行过滤测试等。这通常与 AGENTS.md 更改配对，让它知道这存在。
|
||||
|
||||
**这就是 Mitchell 今天所处的位置。** 他正在真诚地努力，每当看到智能体做坏事时，防止它再做那件坏事。或者，相反，他正在真诚地努力让智能体验证它们在做好事。
|
||||
|
||||
---
|
||||
|
||||
### 阶段 6：始终运行一个智能体
|
||||
|
||||
与阶段 5 同时，Mitchell 也在**始终运行一个智能体**的目标下运作。如果智能体没有运行，他会问自己："现在有什么智能体可以为我做的吗？"
|
||||
|
||||
他特别喜欢将其与较慢、更深思熟虑的模型结合使用，比如 Amp 的 [deep mode](https://ampcode.com/news/deep-mode)（基本上只是 GPT-5.2-Codex），这可能需要 30 多分钟来做小的更改。另一面是它确实倾向于产生非常好的结果。
|
||||
|
||||
**重要说明：**
|
||||
- 他还没有运行多个智能体，目前也真的不想。
|
||||
- 他觉得现在有一个智能体运行是一个很好的平衡，既能做他觉得愉快的深度手动工作，又能照看他有点愚蠢但又神秘高效的机器人朋友。
|
||||
|
||||
"始终运行一个智能体"的目标仍然只是一个目标。他会说现在他在正常工作日的 10 到 20% 时间里有效地运行后台智能体。但他正在积极努力改善这一点。
|
||||
|
||||
> "我不想为了运行智能体而运行智能体。我只希望在有任务我认为对我真正有帮助时运行它们。这个目标的一部分挑战是改善我自己的工作流和工具，以便我能有源源不断的高质量工作可以委托。即使没有 AI，这也很重要！"
|
||||
|
||||
---
|
||||
|
||||
## 今天
|
||||
|
||||
这就是 Mitchell 今天所处的位置。
|
||||
|
||||
通过这段旅程，他个人已经达到了一个点，他在现代 AI 工具上取得了成功，并且相信他正在以基于现实的适当衡量观点来处理它。他真的不在乎 AI 是否会留下来，他是一个软件工匠，只是为了热爱而构建东西。
|
||||
|
||||
整个格局变化如此之快，他相信他会很快回头看这篇帖子，嘲笑自己的天真。但正如他们所说，如果你不能为过去的自己感到尴尬，你可能就没有成长。他只希望他会朝着正确的方向成长！
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Agent|智能体]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. Mitchell Hashimoto - My AI Adoption Journey
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译*
|
||||
@@ -0,0 +1,257 @@
|
||||
---
|
||||
title: "OpenAI Codex Harness 工程"
|
||||
source: "工程技术：在智能体优先的世界中利用 Codex"
|
||||
raw_sources:
|
||||
- path: raw/工程技术：在智能体优先的世界中利用 Codex.md
|
||||
hash: "sha256:initial"
|
||||
tags:
|
||||
- "实践指南"
|
||||
- "OpenAI"
|
||||
- "Codex"
|
||||
- "智能体优先"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# OpenAI Codex Harness 工程
|
||||
|
||||
本文基于 OpenAI 团队的实践经验，探讨如何构建一个**完全由智能体生成代码**的产品开发环境。
|
||||
|
||||
## 核心实验
|
||||
|
||||
在过去五个月里，OpenAI 团队进行了一项实验：构建并交付一款软件产品的内部 beta 版，**其中没有一行代码是人工编写的**。
|
||||
|
||||
### 关键数据
|
||||
|
||||
- **代码量**：约一百万行代码
|
||||
- **时间**：五个月（2025年8月下旬开始）
|
||||
- **团队规模**：从 3 名工程师扩展到 7 名
|
||||
- **PR 吞吐量**：平均每位工程师每天处理 3.5 个 PRs
|
||||
- **效率提升**：只用了手工编写代码所需的大约 1/10 的时间
|
||||
|
||||
> **核心理念**：人类掌舵。智能体执行。
|
||||
|
||||
## 工程师角色的重新定义
|
||||
|
||||
由于缺乏人工编码的实践，**工程师工作的重点转向了系统、架构和杠杆作用**。
|
||||
|
||||
### 深度优先工作方式
|
||||
|
||||
将更大的目标拆解为更小的构建模块（设计、代码、评审、测试等），提示智能体去构建这些模块，并使用它们去解锁更复杂的任务。
|
||||
|
||||
> **关键洞见**：当事情进行不顺利时，解决方案基本上再也不会是"再努力一点"。因为取得进展的唯一方式是让 Codex 来完成工作，而人类工程师则总是介入这项任务并追问："究竟还需要什么样的能力，我们又该如何让这个能力对智能体来说既清晰可读又可强制执行？"
|
||||
|
||||
### 交互方式
|
||||
|
||||
人类几乎完全通过提示与系统交互：
|
||||
- 工程师描述任务
|
||||
- 运行智能体，允许其打开一个 Pull Request
|
||||
- 指示 Codex 在本地审核其自身的更改
|
||||
- 请求额外的特定智能体审查
|
||||
- 对任何人工或智能体给出的反馈做出响应
|
||||
- 循环往复，直到所有智能体审核人员都满意为止（这实际上是一个 [Ralph Wiggum 循环](https://ghuntley.com/loop/)）
|
||||
|
||||
## 提高应用程序的可读性
|
||||
|
||||
随着代码吞吐量的增加，瓶颈变成了人工 QA 能力。解决方案是：**令应用程序的 UI、日志和应用指标等内容对 Codex 直接可读**。
|
||||
|
||||
### Chrome DevTools 集成
|
||||
|
||||
- 令应用程序可以根据 git worktree 启动
|
||||
- 将 Chrome DevTools 协议接入智能体运行时
|
||||
- 创建用于处理 DOM 快照、屏幕截图和导航的技能
|
||||
- 使 Codex 能够复现错误、验证修复，并直接推理 UI 的行为
|
||||
|
||||
|
||||
|
||||
### 完整的可观测性堆栈
|
||||
|
||||
日志、指标和追踪记录会通过一个本地可观测性堆栈展示给 Codex：
|
||||
- 使用 LogQL 查询日志
|
||||
- 使用 PromQL 查询指标
|
||||
- 示例提示："确保服务启动在 800ms 内完成"或"这四个关键用户旅程中的任何跨度都不得超过两秒"
|
||||
|
||||
|
||||
|
||||
## 将代码仓库设为记录系统
|
||||
|
||||
情境管理是使智能体在大型和复杂任务中有效发挥作用的最大挑战之一。
|
||||
|
||||
> **早期经验教训**：要给 Codex 的是一张地图，而不是一本 1,000 页的说明书。
|
||||
|
||||
### "大型 AGENTS.md"方法的失败
|
||||
|
||||
尝试了"一个大型的 AGENTS.md"方法，结果失败了：
|
||||
|
||||
1. **情境是一种稀缺资源** - 一个巨大的指令文件会挤掉任务、代码和相关文档
|
||||
2. **过多的指导反而变得无效** - 当一切都"重要"时，一切都不重要了
|
||||
3. **它会立即腐烂** - 一本庞杂的手册会变成陈旧规则的坟场
|
||||
4. **这很难核实** - 单个 blob 不适合进行机械检查
|
||||
|
||||
### 结构化知识库布局
|
||||
|
||||
因此，不再将 `AGENTS.md` 视为百科全书，而是将其视为**内容目录**：
|
||||
|
||||
```
|
||||
AGENTS.md
|
||||
ARCHITECTURE.md
|
||||
docs/
|
||||
├── design-docs/
|
||||
│ ├── index.md
|
||||
│ ├── core-beliefs.md
|
||||
│ └── ...
|
||||
├── exec-plans/
|
||||
│ ├── active/
|
||||
│ ├── completed/
|
||||
│ └── tech-debt-tracker.md
|
||||
├── generated/
|
||||
│ └── db-schema.md
|
||||
├── product-specs/
|
||||
│ ├── index.md
|
||||
│ ├── new-user-onboarding.md
|
||||
│ └── ...
|
||||
├── references/
|
||||
│ ├── design-system-reference-llms.txt
|
||||
│ ├── nixpacks-llms.txt
|
||||
│ ├── uv-llms.txt
|
||||
│ └── ...
|
||||
├── DESIGN.md
|
||||
├── FRONTEND.md
|
||||
├── PLANS.md
|
||||
├── PRODUCT_SENSE.md
|
||||
├── QUALITY_SCORE.md
|
||||
├── RELIABILITY.md
|
||||
└── SECURITY.md
|
||||
```
|
||||
|
||||
### 渐进式披露
|
||||
|
||||
智能体从一个小而稳定的切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。
|
||||
|
||||
- 专职的 linter 和 CI 作业会验证知识库的更新状况、是否已交叉链接且结构正确
|
||||
- 定期运行的"doc-gardening"智能体会扫描过时或废弃文档，并发起修复用的 Pull Request
|
||||
|
||||
## 目标是智能体的可读性
|
||||
|
||||
由于该代码仓库完全由智能体生成，因此首先针对 Codex 的可读性进行了优化。
|
||||
|
||||
### 智能体知识的局限性
|
||||
|
||||
从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。
|
||||
|
||||
- 存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问
|
||||
- 代码仓库本地的、已版本化的工件（代码、Markdown、模式、可执行计划）就是它所能看到的全部
|
||||
|
||||
|
||||
|
||||
### 将更多情境推送到仓库中
|
||||
|
||||
那次让团队在架构模式上达成一致的 Slack 讨论？如果智能体无法发现它，那么它就会像迟了三个月入职的新员工一样，对其一无所知。
|
||||
|
||||
> **关键原则**：倾向于选择那些可以完全内化于在仓库中进行推理的依赖项和抽象。对智能体来说，通常被称为"枯燥"的技术，由于其可组合性、API 稳定性和在训练集里的表现，往往更容易建立模型。
|
||||
|
||||
## 规范架构与品味
|
||||
|
||||
仅靠文档本身，是没法保持完全由智能体生成的代码库的连贯性的。
|
||||
|
||||
> **核心策略**：通过强制执行不变量，而非对实施过程进行微观管理，我们令智能体能够快速交付，而且不会削弱基础。
|
||||
|
||||
### 示例：在边界处解析数据形状
|
||||
|
||||
要求 Codex [在边界处解析数据形状](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)，但不规定具体实现方式（模型似乎偏好 Zod，但没有指定特定库）。
|
||||
|
||||
### 分层领域架构
|
||||
|
||||
智能体在具有严格边界和可预测结构的环境中最为高效，因此围绕一个严格的架构模型构建了该应用：
|
||||
|
||||
- 每个业务域都划分为一组固定的层
|
||||
- 依赖方向经过严格验证
|
||||
- 仅允许有限的一组边
|
||||
- 通过自定义的 linter 和结构测试机械地强制执行这些约束
|
||||
|
||||
规则：在每个业务领域内（例如应用设置），代码只能"向前"依赖于一组固定的层（Types → Config → Repo → Service → Runtime → UI）。横切关注点（认证、连接器、遥测、功能标志）通过一个单一的显式接口进入：Providers。
|
||||
|
||||
|
||||
|
||||
### 品味不变式
|
||||
|
||||
通过自定义的代码检查器和结构测试来强制执行规则，并辅以一小组"品味不变式"：
|
||||
|
||||
- 结构化日志记录
|
||||
- 模式和类型的命名约定
|
||||
- 文件大小限制
|
||||
- 特定平台的可靠性要求
|
||||
|
||||
> **领导类比**：这类似于领导一个大型工程平台组织：在中央层面强制执行边界，在本地层面允许自主权。你非常重视界限、正确性和可重复性。在这些边界内，你允许团队或智能体在解决方案的表达方式上拥有很大的自由。
|
||||
|
||||
## 吞吐量改变了合并的理念
|
||||
|
||||
随着 Codex 的吞吐量增加，许多传统的工程规范变得不再有效。
|
||||
|
||||
- 代码仓库在运行过程中尽量减少阻塞合并门
|
||||
- Pull Request 的生命周期很短
|
||||
- 测试偶发失败通常通过后续重跑来解决，而不是无限期地阻碍进展
|
||||
|
||||
> **成本权衡**：在一个智能体吞吐量远超人类注意力的系统中，纠错成本低，而等待成本高。在低吞吐量环境中，这样做是不负责任的。而在这里，这通常是正确的选择。
|
||||
|
||||
## "智能体生成"实际上意味着什么
|
||||
|
||||
当说代码库是由 Codex 智能体生成的，指的是整个代码库：
|
||||
|
||||
- 产品代码与测试
|
||||
- CI 配置和发布工具
|
||||
- 内部开发者工具
|
||||
- 文档和设计历史
|
||||
- 评估框架
|
||||
- 审阅评论和回复
|
||||
- 管理代码仓库本身的脚本
|
||||
- 生产仪表板定义文件
|
||||
|
||||
> **人类的角色**：人类始终参与其中，但工作的抽象层次与过去不同。我们优先处理工作，将用户反馈转化为验收标准，并对结果进行验证。当智能体遇到困难时，我们将其视为一个信号：识别缺失的内容 — 工具、指导与约束、文档 — 并将其反馈到代码仓库中，始终由 Codex 自己编写修复。
|
||||
|
||||
## 不断提高的自主水平
|
||||
|
||||
随着越来越多的开发环节被直接编码到系统中，该代码仓库最近跨过了一个重要门槛，使 Codex 能够端到端地驱动一个新功能。
|
||||
|
||||
给定一个提示，智能体现在可以：
|
||||
|
||||
1. 验证代码库的当前状态
|
||||
2. 重现已报告的漏洞
|
||||
3. 录制一个演示故障的视频
|
||||
4. 实施修复措施
|
||||
5. 通过运行应用程序来验证修复
|
||||
6. 录制第二个视频，演示解决方案
|
||||
7. 打开 Pull Request
|
||||
8. 回应智能体和人类反馈
|
||||
9. 检测并修复构建故障
|
||||
10. 仅在需要判断时才交由人工处理
|
||||
11. 合并更改
|
||||
|
||||
## 熵与垃圾收集
|
||||
|
||||
**完全自主的智能体也引入了新的问题**。Codex 会复现代码仓库中已存在的模式 — 甚至包括那些不均衡或不够理想的模式。随着时间的推移，这不可避免地导致漂移。
|
||||
|
||||
### 从人工清理到自动化循环
|
||||
|
||||
最初，人类是手动处理这个问题的：团队过去每周五（占一周的 20%）都要花时间清理"AI 残渣"。不出所料，那并不具备可扩展性。
|
||||
|
||||
### 黄金原则与循环清理流程
|
||||
|
||||
相反，开始将"黄金原则"直接编码到代码仓库中，并建立了一个循环清理流程：
|
||||
|
||||
1. **更倾向于使用共享的实用程序包**，而不是手工编写的辅助工具，以便将不变式集中管理
|
||||
2. **不会使用"YOLO 式"探测数据** — 验证边界，或依赖类型化的 SDK
|
||||
3. **定期运行一组后台 Codex 任务**，扫描偏差、更新质量等级，并发起有针对性的重构 Pull Request
|
||||
|
||||
> **垃圾收集类比**：技术债务就像一笔高息贷款：不断地以小额贷款的方式偿还债务，总比让债务不断累积，再痛苦地一次解决要好得多。
|
||||
|
||||
## 仍在学习的内容
|
||||
|
||||
显而易见的是：构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。保持代码库一致性的工具、抽象和反馈回路变得越发重要。
|
||||
|
||||
> **当前最棘手的挑战**：集中在设计环境、反馈回路和控制系统方面，帮助智能体实现我们的目标：大规模构建和维护复杂、可靠的软件。
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Long-Running-Harness-Design|长运行应用的 Harness 设计]]
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "来源索引"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# 来源索引
|
||||
|
||||
本页面列出 WikiLLM 知识库中所有内容的原始来源。
|
||||
|
||||
## 学术论文
|
||||
|
||||
- [Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering](https://arxiv.org/html/2604.08224v1)
|
||||
- [Meta-Harness: End-to-End Optimization of Model Harnesses](https://arxiv.org/html/2603.28052v1)
|
||||
|
||||
## 概念文章
|
||||
|
||||
- [Harness engineering for coding agent users](https://martinfowler.com/articles/harness-engineering.html)
|
||||
- [Harness Engineering - first thoughts](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html)
|
||||
- [Harness Engineering: The Complete Guide to Building Systems That Make AI Agents Actually Work (2026)](https://www.nxcode.io/resources/news/harness-engineering-complete-guide-ai-agent-codex-2026)
|
||||
|
||||
## 实践指南
|
||||
|
||||
- [Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
|
||||
- [Scaling Managed Agents: Decoupling the brain from the hands](https://www.anthropic.com/engineering/managed-agents)
|
||||
- [工程技术：在智能体优先的世界中利用 Codex](https://openai.com/zh-Hans-CN/index/harness-engineering/)
|
||||
- [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey)
|
||||
- [Improving Deep Agents with harness engineering](https://blog.langchain.com/improving-deep-agents-with-harness-engineering/)
|
||||
- [MiniMax M2.7 开启模型的自我进化](https://www.minimaxi.com/news/minimax-m27-zh)
|
||||
Reference in New Issue
Block a user