> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI Agent 的三次进化
- URL: https://www.hubwiz.com/blog/the-three-evolutions-of-ai-agents/
- Published: 2026-06-02T16:01:05.000Z
- Updated: 2026-06-02T16:01:05.000Z
- Description: 我们构建 AI 的方式在三年内改变了三次。大多数人还在追赶第二次转变。第三次转变已经到来了。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

我们构建 AI 的方式在三年内改变了三次。大多数人还在追赶第二次转变。第三次转变已经到来了。

## 1、第一次转变：提示工程

当 ChatGPT 问世时，每个人都成了提示工程师。

游戏很简单：问更好的问题，得到更好的答案。给模型一个角色。把你的任务分解成步骤。添加示例。链式思考。你的提示越好，输出就越好。

这对一次性任务很有效。提问，接收，完成。

但当我们开始用 AI 构建*产品*时，情况发生了变化。不再是一次性查询，而是需要在步骤间推理、记住事情、在真实系统中采取真实行动的系统。单靠提示已经不够了。

## 2、第二次转变：上下文工程

到 2025 年中，Andrej Karpathy 明确指出：上下文工程比提示工程更重要。

洞察很简单但重要：**模型只能对它能看到的东西进行推理。** 真正的问题不只是*你问了什么*，而是*模型在推理时看到了什么*。

上下文工程是塑造模型输入窗口的一切：系统提示、对话历史、检索的文档、工具定义、记忆注入等。

如果提示工程是"右转"的命令，上下文工程给模型地图、路标和地形，让它真正理解在这种情况下右转意味着什么。

在 Salesforce，Agentforce 的很多基础设计就存在于这一层——在推理时用正确的 CRM 数据、客户上下文和业务规则来让 Agent 落地。正确的上下文是一个听起来有帮助的 Agent 和一个在你的特定业务场景中确实*有帮助*的 Agent 之间的分水岭。

但是一旦 Agent 开始在生产中自主运行，在真实企业系统的多个步骤中采取真实行动，一整套新问题就出现了。更好的上下文无法解决的问题。

![](https://substackcdn.com/image/fetch/$s_!i4t1!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbab39bda-adf3-40f9-9528-b28aec6b27c1_2174x1202.heic)

## 3、第三次转变：Harness 工程

问题是这样的：即使有完美的提示和完美的上下文，一个自主 Agent 仍然会脱轨。

它可能违反你公司的数据访问策略。升级一个它应该解决的案例。触发 Salesforce 中一个无法回滚的操作。或者自信地完全完成了错误的任务。

这些不是上下文问题。它们是*环境*问题。

Harness 工程是设计 Agent 环境的学科：约束、反馈循环、脚手架和运营系统，使 Agent 保持正轨。

在企业世界中，当 Agent 触及客户记录、财务数据和合规工作流时，harness 必须做到所有这些，还要确保信任、安全和可审计性。风险更高，harness 必须更加精心设计。

## 4、Agent = 模型 + Harness

这是最简洁的心智模型：

> **如果你不是模型，你就是 harness。**

围绕模型的一切——代码、配置、工具、记忆、执行逻辑、约束和反馈循环——都是 harness。原始模型不是 Agent。一个带有精心设计 harness 的模型才是一个工作引擎。

三个层次清晰地嵌套：

- **提示工程**问：*我应该问什么？* 它优化指令。
- **上下文工程**问：*模型应该看到什么？* 它优化输入窗口。
- **Harness 工程**问：*整个环境应该如何设计？* 它优化模型周围的系统。

每一层解决不同类别的问题。随着 Agent 承担更多自主的、长期的工作，harness 层的重要性超过了其他两层之和。

## 5、Harness 里有什么？

从 Agent 需要在生产中完成真实工作倒推：

![](https://substackcdn.com/image/fetch/$s_!_ef9!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa59efe03-de1c-4de8-8f72-1a46767871f5_2176x1120.heic)

**持久化状态。** Agent 需要跨会话持久化工作并在轮次之间干净地交接。在 CRM 语境中，这意味着维护案例状态、对话历史和超出单次交互窗口的任务进度。

**工具执行。** 与其为每个场景预先构建刚性操作，不如给 Agent 动态组合和执行工具的能力。在 Agent 中，工具和动作定义了 Agent 的行动空间。Harness 决定这些如何被调用、排序和约束。

**安全执行和护栏。** Agent 生成的动作不能在企业系统中不受检查地运行。Agentforce 中的 Einstein 信任层是 harness 层安全原语的具体例子：屏蔽 PII、阻止不安全输出、强制数据驻留。所有这些都发生在环境层，而不是模型层。

**记忆和落地。** 模型只知道其权重和上下文窗口中的东西。在企业 Agent 中，这意味着在查询时连接到实时 CRM 数据、知识库和客户历史。Agentforce 中的 Data Cloud 落地就是这一层。

**可观察性和反馈循环。** 在生产中，harness 包括你用来理解 Agent 在做什么的一切：追踪、评估、会话日志和将 Agent 行为反馈到 harness 改进的闭环机制。这是大多数企业团队投资不足的地方，而且往往是最具杠杆的起点。

## 6、从期望的 Agent 行为倒推到 Harness 工程

Harness 工程是关于引导 AI Agent 以我们期望的方式行为。它让人类添加结构、规则和上下文，使模型能更可靠地执行有用的任务。随着模型的改进，harness 也被用来扩展它们的能力和修复局限。

与其列出每一个 harness 功能，核心思想很简单：

**从你期望的 Agent 行为开始，然后设计 harness 来实现该行为。**

![](https://substackcdn.com/image/fetch/$s_!dnQH!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feb3a4a34-12f8-443f-bda6-9e0fe6ee6343_2168x1208.heic)

---

原文链接：[From Prompts -> Context -> Harness Engineering: The Evolution of Building AI Agents](https://manjeet.substack.com/p/from-prompts-context-harness-engineering)

汇智网翻译整理，转载请标明出处