AI Agent 的三次进化

我们构建 AI 的方式在三年内改变了三次。大多数人还在追赶第二次转变。第三次转变已经到来了。1、第一次转变提示工程当 ChatGPT 问世时每个人都成了提示工程师。游戏很简单问更好的问题得到更好的答案。给模型一个角色。把你的任务分解成步骤。添加示例。链式思考。你的提示越好输出就越好。这对一次性任务很有效。提问接收完成。但当我们开始用 AI 构建产品时情况发生了变化。不再是一次性查询而是需要在步骤间推理、记住事情、在真实系统中采取真实行动的系统。单靠提示已经不够了。2、第二次转变上下文工程到 2025 年中Andrej Karpathy 明确指出上下文工程比提示工程更重要。洞察很简单但重要模型只能对它能看到的东西进行推理。真正的问题不只是你问了什么而是模型在推理时看到了什么。上下文工程是塑造模型输入窗口的一切系统提示、对话历史、检索的文档、工具定义、记忆注入等。如果提示工程是右转的命令上下文工程给模型地图、路标和地形让它真正理解在这种情况下右转意味着什么。在 SalesforceAgentforce 的很多基础设计就存在于这一层——在推理时用正确的 CRM 数据、客户上下文和业务规则来让 Agent 落地。正确的上下文是一个听起来有帮助的 Agent 和一个在你的特定业务场景中确实有帮助的 Agent 之间的分水岭。但是一旦 Agent 开始在生产中自主运行在真实企业系统的多个步骤中采取真实行动一整套新问题就出现了。更好的上下文无法解决的问题。3、第三次转变Harness 工程问题是这样的即使有完美的提示和完美的上下文一个自主 Agent 仍然会脱轨。它可能违反你公司的数据访问策略。升级一个它应该解决的案例。触发 Salesforce 中一个无法回滚的操作。或者自信地完全完成了错误的任务。这些不是上下文问题。它们是环境问题。Harness 工程是设计 Agent 环境的学科约束、反馈循环、脚手架和运营系统使 Agent 保持正轨。在企业世界中当 Agent 触及客户记录、财务数据和合规工作流时harness 必须做到所有这些还要确保信任、安全和可审计性。风险更高harness 必须更加精心设计。4、Agent 模型 Harness这是最简洁的心智模型如果你不是模型你就是 harness。围绕模型的一切——代码、配置、工具、记忆、执行逻辑、约束和反馈循环——都是 harness。原始模型不是 Agent。一个带有精心设计 harness 的模型才是一个工作引擎。三个层次清晰地嵌套提示工程问我应该问什么它优化指令。上下文工程问模型应该看到什么它优化输入窗口。Harness 工程问整个环境应该如何设计它优化模型周围的系统。每一层解决不同类别的问题。随着 Agent 承担更多自主的、长期的工作harness 层的重要性超过了其他两层之和。5、Harness 里有什么从 Agent 需要在生产中完成真实工作倒推持久化状态。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 来实现该行为。原文链接AI Agent 的三次进化 - 汇智网