驾驭工程全景：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的三级跃迁
2020 年我们学会了跟模型说话（Prompt Engineering），2025 年我们学会了给模型喂信息（Context Engineering），2026 年我们学会了给模型搭脚手架（Harness Engineering）。这三个 Engineering 不是并列关系，而是严格的超集关系：PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角，系统梳理这条演进路径上的每一次范式跃迁。 一个类比秒懂三级跃迁 在讲技术之前，先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席： Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行，得说"用中火煎三分钟，翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统，让厨师在需要的时候拿到需要的东西。 Harness Engineering 就是学会怎么...
harness的一种实践方法
当我们让 AI Agent 实现一个功能，它思考了一下，开始写代码。200 行写完，运行 lint 直接失败。我们发现类型定义文件 import 了配置包，但是违反了我们期望的架构分层约束，因为 Agent 不知道这个规则，当然我们也没告诉它。 于是它开始修复：移动代码、调整依赖、重新组织。再跑 lint——又一个新问题。循环三次后，上下文窗口被错误日志和 diff 塞满，Agent 开始"忘记"最初的任务目标。 这不是 Agent 不够聪明。这是 Agent 看不见。 你可能也遇到过类似的事情：同一个项目，昨天的 AI 还记得你们的架构约定，今天开个新会话又全忘了。每次协作都要重新解释一遍背景、分层规则、命名规范。AI 生成的代码能跑，但完全不符合团队规范，code review 时才发现一堆问题。让它修 bug，结果引入了新 bug——没有自动验证，全靠人肉检查。 如果换成一个新入职的工程师，他可能也不熟悉代码库，但至少会问一句：“这个文件应该放在哪个目录？”"这样 import 可以吗？"他在行动前寻求验证。AI Agent 不会。它...
长时任务的 Harness 设计艺术
原文：Harness design for long-running application development 作者：Prithvi Rajasekaran，Anthropic Labs 团队成员 发布日期：2026 年 3 月 24 日 Harness 设计是前沿 Agent 编程性能的关键所在。本文介绍我们如何在前端设计和长时自主软件工程两个方向上，将 Claude 的表现大幅推进到基线之上。 过去几个月，我一直在研究两个相互关联的问题：如何让 Claude 生成高质量的前端设计，以及如何让它在无人干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计 Skill 和长时编程 Agent Harness 上的探索——通过提示词工程和 Harness 设计，我和同事们将 Claude 的表现大幅提升到了基线之上，但两个方向最终都遇到了瓶颈。 为了突破这一瓶颈，我寻找了在两个截然不同领域都能奏效的新型 AI 工程方法——一个领域以主观审美为核心，另一个以可验证的正确性和可用性为核心。受生成对抗网络（GAN）的启发，我设计了一种包含生成器和评估器 Agent 的...
OpenSpec 实战指南：从工作流到落地
为什么需要 OpenSpec 在 AI 编程时代，真正的难点往往不是“AI 会不会写代码”，而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力，而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实，AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话：先对齐规范，再生成代码（align before code）。与其把 AI 当成一个只看提示词的即时执行器，不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台，也不是传统瀑布式文档系统。从实践上看，它更像一套轻量的仓库内协议： 用 specs/ 保存系统当前已经成立的事实； 用 changes/ 保存本次准备引入的未来变化； 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达； 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学，基本可以概括为四点： Fluid not rigid：规范是活文档，不...
子 Agent 的本质：上下文隔离与专门化
"子 Agent"这个词在多 Agent 系统的讨论中频繁出现，却鲜有人把它说清楚。它是一个能力弱化的 Agent，类似一个 Agent 化的工具？还是一个拥有更小上下文的原始 Agent，像从主 Agent fork 出来的进程？还是一个在指挥体系里听从领导 Agent、但拥有更强资源和能力的 Agent？ 这三种直觉都不完全准确。本文从 Anthropic、LangChain、Claude Code 等权威来源出发，厘清子 Agent 的真实本质，并探讨一个更深层的问题："子 Agent"究竟是能力描述，还是关系描述？ 三种直觉，三种误解 在深入定义之前，先把三种常见直觉逐一检验。 误解一：子 Agent 是能力弱化的 Agent 这种直觉来自于"子"字的字面含义——子集、子系统、子进程，往往意味着更小、更弱。但 LangChain 官方文档明确指出： “An interesting aspect of this approach is that sub-agents may have the exact sam...
Coding Agent 架构祛魅：从 Claude Code 到 OpenCode 的真实实现
围绕 Coding Agent 的讨论，常见两种极端：将其神化为自主智能体，或将其贬为"不过是提示词工程"。两种判断都失之简单。本文从真实的架构出发，拆解 Claude Code、OpenCode 等工具的实现模式，厘清各自的设计取舍，以及那些被反复误解的核心问题。 一个循环统治一切 先说结论：所有 Coding Agent 的核心，都是一个 while(tool_use) 循环。 通过对 Claude Code 实际 API 流量的追踪分析，其核心逻辑可以用伪代码描述如下： 12345678while True: response = llm.call(context) if response.has_tool_call(): result = execute_tool(response.tool_call) context.append(result) else: # 没有工具调用 = 任务完成，等待用户输入 break 没有复杂的状态机，没有多 Agent 协调框架，没有专门的&...
git worktree 术语起源解析
引言 在使用 Git 的过程中，你可能会遇到 git worktree 这个命令。这个名字看起来有些特别——为什么叫 “worktree” 而不是 “workspace” 或其他更常见的词？这背后其实有一段有趣的技术历史。 核心答案 worktree 是 working tree（工作树）的缩写，来源于 Git 内部的核心概念。 这不是一个凭空创造的新词，而是直接引用了 Git 自诞生以来就存在的基础术语。 Git 的三大核心区域 要理解 worktree 的命名，首先需要了解 Git 的三大核心区域： 区域 英文名称 别名 作用 仓库 Repository - 存储所有版本历史和元数据（.git 目录） 工作树 Working Tree Working Directory 用户实际编辑文件的目录 暂存区 Index Staging Area 准备提交的文件快照 Working Tree 的含义 Working Tree（工作树）指的是检出（checkout）到文件系统中的文件集合。它是你能够直接看到、编辑的目录和文件。 12345my-project...
告别 Vibe Coding：用 OmO 构建可靠的 AI 工程系统
引言：AI 编程的范式跃迁 过去一年，AI 编程工具从对话式代码生成器进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码，而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode（简称 OmO）正是为了解决这一问题而生。它不是另一个聊天框，而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位：工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量"，而 OmO 的核心目标是**“工程交付”**。 OmO 的工作流程遵循"输入 Markdown 描述，输出可运行代码"的心智模型： 12341. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出 (任务描述、 (Intent Gate (并行搜索、 (回到 build/ repo 上下文、 分清提问/修复/ 资料、执行...
智能体外部记忆：文件标准现状与超越 Harness 的更广泛用途
当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式？除了用在 Harness Engineering 里，还有哪些更广泛的用途？本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战，以及超越 Harness 的更广泛应用场景。 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此，业界已经形成了几个被广泛认可的...
在智能体优先的世界中利用 Codex
原文作者：Ryan Lopopolo，OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里，我们的团队一直在进行一项实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计，我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制，以便构建必要的内容，从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此，我们需要了解，当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。 这篇文章要说的是，在我们与智能体团队一起从零开始打造一款全新产品的过程中，所...
