企业官网建设流程全解析

Harness 工程

过去很长一段时间里，大家一提到“大模型怎么用好”，第一反应往往是：Prompt 怎么写？

于是，Prompt Engineering 成了很多人学习大模型的第一站。我们学习如何提问，如何给角色，如何写任务，如何给示例，如何让模型一步一步思考。

但随着大模型从“聊天工具”逐渐变成“能写代码、能调用工具、能执行任务的 Agent”，问题开始变得更复杂了。

你会发现：
一个 Agent 做得好不好，已经不只是 Prompt 写得好不好。它还取决于：

它能看到什么上下文？
它能调用什么工具？
它有没有记忆？
它有没有自动验证机制？
它犯错之后系统能不能让它不再犯同样的错？

这就引出了三个非常重要的概念：

Prompt Engineering、Context Engineering、Harness Engineering。

它们不是互相替代的关系，而是一层一层往外扩展的关系：

Prompt Engineering 研究怎么提问题。
Context Engineering 研究怎么给信息。
Harness Engineering 研究怎么搭系统。

下面我们就从这三个概念开始，系统梳理一下大模型 Agent 背后的工程方法论

一、Prompt Engineering

研究怎么提问题，怎么把发给大模型的话说得更清楚、更准确，让大模型更容易理解你的真实意图，然后给出理想的结果。

常用的Prompt Engineering 范式

• Instruction Prompting 指令式提示词

  • 核心是：告诉模型你要做什么

  • 例如：

（1）写一个函数，实现两个整数的加法，输入两个整数，输出它们的和。 （2）你是一个专业的代码审核员，你需要审核这段代码是否符合规范。 这里已经包含了几个Prompt 的重要元素：Role、Task、Input、Output。

• Example-driven 示例式提示词 LLM 最大的特点就是通过例子学习

  • 核心是：给模型举几个例子，让它理解你要做什么。

  • 例如：

英文：hello 中文：你好 英文：goodbye 中文：再见 英文：thank you 中文：？

• Chain-of-Thought（CoT）范式

  • 核心是：通过提示词强制模型显式展开中间推理，而不是直接给出答案。让模型先分析，再给结论。
  • 例如：

一个商品100块，打8折再减少10块，问最终价格是多少 普通prompt，直接回答结果，模型说70块。 Cot Prompt 请一步一步思考，并给出最终答案。 模型会这样输出： 原价100； 打8折：100*0.8=80； 减少10块：80-10=70； 最终价格：70块。

• ReAct 范式

  • 核心是：在思考的基础上，让模型可以调用工具去行动。
  • 例如：

东京今天天气怎么样？是不是和跑步？ 普通prompt，直接回答结果，模型说天气是晴的，适合跑步。 ReAct Prompt 请一步一步思考，并给出最终答案。 模型会这样输出： Thought:我需要获取东京今天的天气。 Action:调用天气API，获取东京今天的天气。 Observation:返回天气数据 Thought:根据天气数据判断是否适合跑步。 Final Answer:适合跑步。

二、Context Engineering

研究的是怎么给信息，具体来说就是怎么把最合适的内容在最合适的时机放到模型的Context 中。Context里面的内容不仅包括Prompt，还有工具列表、对话历史等等。

上下文工程的方法：

1.上下文压缩

大模型的上下文窗口再大，也不是无限的。
如果把所有项目规则、历史对话、设计文档、代码片段一股脑全部塞进去，结果往往并不好。

因为信息太多时，模型可能会：抓不住重点，忽略关键约束，引用过时内容，被无关信息干扰，输出变得不稳定。

所以上下文压缩非常重要。

上下文压缩不是简单地“删短”，而是把大量信息整理成更高密度的结构。

比如把一段长长的会议记录压缩成：

项目目标 关键决策 未解决问题 接口约定 风险点 下一步行动

这样模型看到的是“结构化知识”，而不是一堆散乱文本。

2.动态检索外部资料

很多信息不需要每次都塞进上下文。
更好的方式是：用到的时候再检索。

比如你有一个大型代码仓库，不可能每次都把所有代码发给模型。
正确做法是让模型根据当前任务动态检索相关文件。

要改登录逻辑，就检索登录模块。
要查接口定义，就检索 API 文档。
要修数据库问题，就检索 Repo 层代码和 schema。

这就是 RAG、代码检索、文档检索背后的思路。

模型需要的不是“所有信息”，而是“当前任务最相关的信息”。

3.渐进式披露

渐进式披露的意思是：

不要一开始就把所有复杂信息都丢给模型，而是随着任务推进，逐步提供信息。

比如做一个复杂功能时，可以先让模型看需求文档，产出设计方案。
确认方案后，再让它看相关代码。
写完代码后，再给它测试结果。
如果测试失败，再把错误日志给它。

这个过程就像人类工程师工作一样：

先理解需求 再阅读代码 再动手修改 再运行验证 再根据反馈修复

渐进式披露可以让模型始终聚焦在当前阶段，而不是被所有信息同时轰炸。

三、Harness Engineering

Harness 原意是马具，用来控制大模型的系统。

既然是控制大模型，那么Harness 就不包含大模型。
所以Harness = Agent - Model。Agent 除了大模型，剩下的所有部分都是Harness。

Agent = Model + Harness（五个组件）

• Tools 工具是模型的手脚 Read、Write、Edit、Bash、Grep（检索命令）
  这些工具赋予模型予文件系统、终端、网络交互的能力
  没有工具，模型就只能说，不能做。

• Context（上下文）模型的记忆加载器 CLAUDE.md、系统提示词、对话历史、工具定义这些上下文在每一轮循环被注入模型，决定模型看到什么、知道什么。上下文管理的精妙在于，它不仅是被动的信息传递，还包括主动的压缩和重新注入策略（成长）。

• Memory（记忆）模型的长期存储。跨会话的记忆持久化，让模型能记住你的偏好、项目规划和历史决策。CLAUDE.md 显示记忆自动记忆 ~/.claude/memory 存下你的操作习惯，没有memory，每次对话都从0开始。

• Hooks 钩子，模型的神经反射。
  事件驱动的自动化机制，在工具执行前后发出自定义逻辑。在工具执行前后触发自定义逻辑。比如每次保存文件自动格式化，每次提交代码自动测试代码。不需要模型主动决策，某些行为会自动发生。

• Permissions 权限，模型的权限管理。
  模型的安全围栏，哪些工具可以自由使用，哪些需要人工审核，哪些完全禁止。harness 的安全底线。你希望Agent 足够自主以提高效率，但又不希望它自主到失控。

用Claude 来举例，所有不属于Claude 模型的部分都是Harness。比如说写在CLAUDE.md 里面的规则，可以使用的工具，定时调度机制，都是属于Harness 的一部分。

Harness 知道了，那么Harness Engineering 就是一门专门构建和设计Harness 的技术。换而言之，就是除了大模型本身不研究，其他什么都研究。具体来说就是研究如何围绕着大模型搭建一个完整可靠的Agent。

核心理念就是，只要Agent 犯了错，你就去改造系统，让它不再犯同样的错误。

Harness Engineering 实战 来源于OpenAI

文章来源：https://openai.com/index/harness-engineering/

具体内容大概如下。

2025年8月，OpenAI 内部启动了一项实验：完全依靠 AI 从零到一开发一款真实软件产品，全程不允许工程师手写一行代码。 依托 AI 自主开发，这款产品最终规模达到100万行代码，整体耗时约5个月，团队仅7人，整体开发效率约为传统人工开发的10倍。

但这项实验初期进展并不顺利，问题不在于大模型不够聪明，而是Harness 工程体系没有搭建完善。工程师发现 Agent 很容易偏离目标方向，还会反复犯同类错误。 想要让 Agent 稳定、可靠地工作，真正的核心关键，在于设计完善的 Harness 体系。

为此团队做了大量优化工作，并撰写专业文章完整记录整个落地过程，文中梳理了大量 Harness Engineering 的优化要点。 所有优化方向大致归为三大类：上下文管理、验证与反馈、技术债清理。

1.上下文管理。

如果把所有的项目规范和相关信息都塞进一个 AGENTS.md 文件，这个文件体量会变得极其庞大，并且会随着用户提问一同发送给大模型。这样会造成两个核心问题。

第一个，内容冗余过多，实际使用效果反而变差。大模型容易淹没在海量信息里陷入迷失，只能抓取零散碎片，真正关键的核心内容，反而被冗余信息覆盖埋没。

第二个，文件会逐步腐化失效。项目是持续迭代演进的，但文件内的规范和信息无法同步及时更新，久而久之就会沦为堆满过时信息的垃圾堆，Agent 也无法甄别判断哪些内容真实有效。

解决办法是把 AGENTS.md 精简压缩到 100 行左右，只作为索引目录使用，把各类配套规范、相关文档拆分出来，和精简后的 AGENTS.md 放在同一目录下，做到用到哪一块，再单独给 Agent 读取对应板块内容，精准度和执行效果会大幅提升。

还有一个关键问题：项目里很多重要信息，其实并不在代码仓库内，而是零散存放在历史对话记录、外部文档，甚至只留存于个人认知里。但对 Agent 而言，只能识别代码仓库内的内容，仓库之外的所有信息，对它都是不可见、不生效的。所以 OpenAI 强制要求，必须把项目所有重要决策、团队约定、规范标准全部纳入代码仓库，让代码仓库成为项目唯一的事实来源。

2.验证和反馈。

做好上下文管理，Agent 就具备了编写代码的基础能力。后续核心重点，是让 Agent 在写完代码后，能够自主验证成果是否正确。如果只能生成代码却无法自我校验，就根本没法保证输出正确率。

OpenAI 的思路是给 Codex 配置足够完善的工具（tools）与技能（SKILLs）。依托这两者，Codex 在执行任务的过程中，可以随时对自己的输出做自检验证。

比如将 Chrome DevTools 接入 Codex 运行环境，Codex 就能自主截图、查看 DOM 结构、模拟用户交互操作，以此校验 UI 表现是否符合需求。一旦发现问题，可就地自查自纠、即时修复，全程无需人工介入。

同时 OpenAI 还为 Codex 接入了完整可观测性工具栈，支持读取日志、追踪运行链路，自主定位和排查运行异常。

另外，OpenAI 把待开发系统做了分层设计，并制定严格的单向依赖规则。自上而下依次为：UI（视图层）、Runtime（运行时层）、Service（业务逻辑层）、Repo（数据访问层）、Config（配置层）、Type（类型定义层）。上层只能依赖下层，严禁反向依赖，并通过 Linter + 测试机制强制守住架构规范。

整套形成闭环流程：Agent 生成代码 ➜ Linter / 自动化测试检测 ➜ 发现违规或问题 ➜ 抛出报错 ➜ 把错误信息回传给 Agent 重新修改

循环迭代往复，直至检测无报错，确认代码完全符合架构与编码规范，全程自动化闭环，无需人工干预。

3.技术债务清理。

Agent 在大规模生成代码时，难免会引入糟糕的设计模式，比如重复代码、命名不一致、偏离架构的写法等。这类问题长期累积，会直接导致代码仓库变得混乱不堪。

OpenAI 的解决方案是对技术债进行定期 “垃圾回收”：为 Codex 设置后台定时任务，定期扫描整个代码库，自动识别偏离规范的代码，自动修复并提交，持续保证代码质量维持在较高水准。

同时对项目文档执行相同机制，通过定时任务扫描文档库，自动清理过时内容、修正与实际代码不一致的文档，保持文档时效性与准确性。

结语

大模型本身当然重要。
模型越强，Agent 的上限越高。

但在真实工程场景里，决定 Agent 是否可靠的，往往不是模型一个因素，而是整个 Harness 系统。

Prompt 写得好，可以让模型更懂你的需求。
Context 管得好，可以让模型更懂当前任务。
Harness 设计得好，才能让模型稳定、可控、可验证地完成复杂工作。

未来的大模型工程，不会只停留在“怎么写 Prompt”。
它会越来越像软件工程、系统工程和自动化工程的结合。

一个成熟的 AI Agent，不应该只是“会回答问题”，而应该是：

有工具的执行者，
有上下文的协作者，
有记忆的长期伙伴，
有权限边界的安全系统，
有反馈闭环的自我修复机器。