文章目录引言Demo 与产品之间的那道沟一、Agent LLM 上下文 工具1.1 同一个对象的三层语言1.2 一条容易被忽略的边界Agent 不包含 Environment二、真正的能力杠杆观察空间与动作空间三、手脚工具的五类划分与粒度取舍3.1 工具调用的四步流程3.2 通用工具与专用工具一条不该走极端的取舍线四、大脑从“模型即 Agent”到 Harness 的节奏问题4.1 模型即 Agent编排没有消失只是搬了位置4.2 苦涩的教训方向认同节奏务实4.3 Agent 的行为如何改变三条时间尺度不同的路径五、眼睛上下文的五个组成部分5.1 消融实验每个组件缺了会怎样六、ReAct 循环轨迹如何驱动任务推进七、Harness 工程模型之外的竞争力7.1 五层递进从提示工程到 Graph 工程7.2 三条核心原则八、编排模式工作流与自主 Agent8.1 工作流确定性编排8.2 自主 Agent动态决策8.3 混合才是常态九、护栏按“被绕过的难度”分三层9.1 上下文层管模型能看到什么9.2 执行层管模型能做什么9.3 数据层管世界最终能被改成什么样9.4 两个容易被忽视的实践细节十、五个反复出现的设计模式结语把认知锚在四个判断上引言Demo 与产品之间的那道沟用 Cursor 写过代码的人都见过这样的场面你描述一个需求它开始搜索代码库、跨文件修改、跑测试、看到报错再改回来直到测试变绿。用 Deep Research 调研过一个课题的人也熟悉另一种场面它反复检索、阅读、交叉验证最后交出一份带引用的报告。再往前一步Manus 会替你操作浏览器完成在线流程手机助手会替你在 App 里订票发消息Pine AI 甚至会替你打电话给运营商砍账单。这些产品形态差别很大但共同点非常明确它们不再是“问一句答一句”的被动对话系统而是能自主规划步骤、调用工具、根据结果调整策略的执行系统。问题在于能跑起来的 Demo 和能交付业务的产品之间隔着一条很深的沟。同一套机制在演示环境里跑通一次很容易在生产环境里连续跑一万次而不出事故就很难模型会编造不存在的工具名会选错工具会在报错后原地打转会在任务只完成一半的时候宣布“已完成”。这篇文章要建立的就是跨越这条沟所需要的概念坐标系Agent 到底由什么构成、能力杠杆在哪里、以及为什么在模型能力快速商品化的今天真正的工程竞争力反而落在了模型之外的那一层——Harness。本文面向已经调用过大模型 API、写过一点工具调用代码但还没有把 Agent 送进生产环境的开发者和研究者。读完之后你应该能回答三个问题给定一个失败的 Agent 任务该加模型、加上下文还是加工具一个生产级 Agent 系统的代码里到底大部分在做什么什么时候该用固定流程什么时候该放手让模型自己决定一、Agent LLM 上下文 工具现代 Agent 的最小工程实现可以压缩成一个公式Agent LLM 上下文 工具这里的加号表示工程组件的组合不是强化学习里的形式化定义。三个词都需要做广义但边界清楚的理解。LLM 是大脑。它不只是一堆参数而是整个决策内核理解意图、拆解任务、判断下一步。就像人类大脑不只是神经元的集合还包括被经验塑造出来的思维习惯LLM 的能力也来自两部分——预训练积累的世界知识与语言能力以及后训练固化下来的决策策略。上下文是眼睛。它不只是那段拼进去的文本而是 Agent 在每个决策点实际收到并保留的全部信息表示环境返回的观察、用户记忆、领域知识、自身状态、任务进展。工具是手脚。它指 Agent 用来感知或改变外部世界的接口包括工具定义、调用协议和适配器——从预定义的函数调用到动态生成代码到委托子 Agent再到主动联系用户。换成更直观的说法就是Agent 大脑 眼睛 手脚。大脑负责思考决策眼睛接收环境提供的观察手脚把决策变成作用于环境的行动。1.1 同一个对象的三层语言同一件事有三套说法分别服务于不同的沟通场景。混用不同层的术语是很多技术讨论跑偏的根源所以值得先对齐直觉层实现层学术层RL含义大脑LLM策略 Policy面对当前信息从所有可选行动中挑一个眼睛上下文构造观察与历史把环境返回的观察与已有历史组织成决策所需的信息手脚工具与适配器观察 / 动作接口规定能读什么、能发什么、接口格式是什么需要强调的是这里不是严格的一一等同。上下文是“具体观察和历史在 Agent 内部的表示”不等于整个观察空间工具定义了可用的观察与行动接口但工具背后的对象仍然属于环境。1.2 一条容易被忽略的边界Agent 不包含 Environment在经典强化学习和控制论的视角里Agent 与 Environment 是闭环交互的两方而不是彼此的组成部分。环境不断向 Agent 返回观察Agent 根据已有上下文选择行动行动改变环境状态新状态又产生下一次观察。这是理解所有 Agent 交互的最小结构。把这条边界画清楚之后Agent 内部还能再分一层Model 只负责策略决策Harness 是 Agent 边界内、环绕模型的运行与治理层负责构造上下文、暴露工具接口、维护循环和状态并实施权限、验证与纠正。Environment状态与转移规律 ↑ 行动 ↓ 观察 ┌─────────────────────────────┐ │ Agent │ │ ┌─────────────────────────┐ │ │ │ Harness运行与治理层 │ │ │ │ 上下文构造 · 工具接口 │ │ │ │ 循环 · 状态 · 权限 │ │ │ │ 验证 · 纠正 │ │ │ │ ┌─────────────┐ │ │ │ │ │ Model │ │ │ │ │ │ 选择下一步 │ │ │ │ │ └─────────────┘ │ │ │ └─────────────────────────┘ │ └─────────────────────────────┘这条边界在实践中有一个反直觉的推论物理部署位置不决定概念归属。即使仿真环境和 Agent 跑在同一个进程里它依然是 Environment沙箱的权限配置与重置机制属于 Harness而沙箱内那些随行动变化的文件和进程属于 Environment。搞混这一点评估时就会把“环境自身的状态漂移”误判成“Agent 的能力退化”。于是最小公式可以重新展开LLM 对应 Model“上下文 工具”构成最小 Harness生产系统会在同一边界内继续加入约束、验证和纠正。二、真正的能力杠杆观察空间与动作空间观察通道与动作接口共同构成 Agent 与外部世界之间的边界这条边界有两个残酷的性质没有通过观察通道进入上下文的信息对模型来说等于不存在没有被动作接口允许的操作模型即使知道该怎么做也只能停留在文字建议上。由此得到一条极其实用的工程判据在底层模型固定时提升任务表现最主要的手段是重新定义或扩展观察空间与动作空间也就是扩展上下文和工具。很多看起来需要“更聪明的模型”的问题本质上只是接口问题。Agent 反复答错某个业务问题可能只是因为那张关键的费率表从来没进过上下文Agent 总是绕圈子可能只是因为它缺少一个“读取当前订单状态”的工具只能靠猜。两个产品演进案例把这条判据讲得很透。Manus把原本分离的空间合并。在 Manus 之前生产级 Agent 大体沿着三条相对独立的路线发展Deep Research深度调研、Coding代码生成、Computer Use电脑操控。Manus 的突破在于把三者放进同一个有广泛影响力的产品虚拟浏览器扩大了观察空间文件系统、代码执行与命令行扩大了动作空间。它不是靠换一个更强的模型成为通用 Agent而是取了三类 Agent 观察空间与动作空间的并集。OpenClaw把接口延伸进用户的数字生活。它通过用户已经在用的 WhatsApp、Telegram、Slack、Discord、iMessage 等渠道接收任务、返回结果让 Agent 随时可被触达同时用本地 Gateway 连接 Google Drive、Notion 等云应用和本地文件系统。相比早期以隔离云沙盒为中心、需要手工上传文件的形态本地优先的路线跨越了更大的数据边界。有意思的是Manus 后来也补上了 Google Drive 连接器与桌面端本地访问——产品能力的演进往往就是观察空间和动作空间的演进。把主流 Agent 产品按三个维度拆开对照这条规律会更清楚产品类型眼睛感知手脚行动策略Coding Agent需求、代码片段、目录列表、终端输出代码搜索、文件读写、执行命令理解需求 → 搜索 → 编辑 → 测试 → 修复搜索型 Agent搜索结果、网页内容、论文摘要与引用搜索查询、网页读取、生成报告迭代深化按已有信息调整检索方向电脑操控 Agent屏幕截图、DOM 或无障碍树、操作结果点击、输入、滚动、截图、执行代码观察屏幕 → 识别元素 → 操作 → 验证手机助手 Agent手机截图、App 界面状态、系统反馈点击、滑动、输入、打开 App意图理解 → 定位 App → 操作 → 确认个人办事 Agent授权读取的账户记录、账单、服务商资料打电话、发邮件、填表单、与用户确认收集信息 → 制定策略 → 联系 → 谈判 → 汇报这些系统共享三个特征动作空间是开放式的能生成任意自然语言和代码而不是从几个按钮里选能在行动前内部思考能根据环境反馈持续调整。三、手脚工具的五类划分与粒度取舍按 Agent 与外界互动的方向工具可以分成五类。这个分类不是为了整齐而是因为五类工具的调用方式、失败模式和安全策略都不一样。感知工具让 Agent 拿到信息。搜索引擎提供实时网络数据文件系统读取本地文档API 与数据库对接外部服务和企业核心数据。执行工具让 Agent 改变世界。代码执行、文件操作、系统命令、外部 API 调用——决策由此变成实际行动。协作工具让 Agent 与其他智能体或人分工。委托子 Agent 处理专项任务在关键决策点请求人类确认。事件触发工具与前三类有本质区别它不是 Agent 主动调用的而是作为外部输入驱动 Agent 开始执行。新邮件、定时器、Webhook 回调都属于这一类它同样是环境向 Agent 提供观察的通道。用户沟通工具Agent 主动与用户建立连接、传递信息的渠道。它不改变外部世界只负责把进展、确认请求或主动关怀送到用户面前。3.1 工具调用的四步流程工具调用Tool Calling也叫 Function Calling把 LLM 从文本生成器变成能执行操作的系统流程只有四步第一步声明工具 第二步模型决定调用tools:[{assistant:{name:get_weather,tool_calls:[{parameters:{city:string}function:get_weather,}]arguments:{city:北京}}]}第三步结果追加到上下文 第四步模型基于结果回复tool:{assistant:{tool_call_id:call_1,content:北京今天 28°C晴。content:{temp:28,sky:晴}}}开发者负责的只有两件事定义工具、执行调用。“要不要调、调哪个、传什么参数”由模型自主决定。这个循环就是后文 ReAct 的基础。3.2 通用工具与专用工具一条不该走极端的取舍线设计工具时合理的起点是任务所需的最窄能力再随复杂度提升逐步扩展。如果任务只是四则运算一个参数清晰的计算器就够了。当任务升级为“读表格、清洗缺失值、算统计量、画图”一个受限的 Python 解释器就比不断叠加专用工具更容易组合和探索——因为组合的可能性是乘法级的而专用工具是加法级的。但通用性同时放大了出错面和攻击面。代码必须在隔离沙盒里跑默认不能访问网络不能读取授权工作目录之外的文件并对执行时间、CPU、内存、输出大小设上限。反过来说通用工具并不总是优于专用工具。支付、删除数据、发送邮件、生产部署这类高风险或强业务约束的操作仍然应该封装成参数明确、权限受限、全程可审计的专用工具必要时再加预览和人工确认。一句话总结通用基础能力用于组合与探索专用工具用于约束高风险和强业务规则操作。长程任务还有一条补充规则。单一日志工具适合记录一段执行过程但对需要数小时甚至数天的任务一个受控的虚拟工作目录更合适计划、中间结果、运行日志和最终产物都放在里面Agent 能在多次执行之间接续工作。这个目录同样要限定可读写路径、容量、文件类型并防止路径越界。四、大脑从“模型即 Agent”到 Harness 的节奏问题LLM 作为决策核心拿到请求后要先解析真实意图——用户说的往往不是他真正想要的——再把模糊任务拆成可执行步骤并在执行中持续判断下一步做什么。这个过程可以分解为三个关键阶段1. 意图解析与需求澄清用户表达的需求往往包含隐含假设、未明说的约束和模糊的边界条件。例如“帮我分析一下销售数据”这个请求背后可能隐藏着“按地区对比季度增长率”、“识别异常交易模式”或“预测下个月趋势”等不同具体目标。成熟的 Agent 系统会通过主动提问来澄清这些模糊点而不是盲目开始执行。这种意图澄清能力通常通过两种方式实现一是模型内置的对话式澄清如 Claude 的“思考后再回答”模式二是在 Harness 层设计专门的澄清节点在工具调用前先确认关键参数。2. 任务分解与规划将高层目标拆解为可执行的原子操作。这不仅仅是简单的步骤列表而是要考虑依赖关系哪些步骤必须先于其他步骤执行并行可能性哪些步骤可以同时进行以提高效率资源约束工具可用性、权限限制、时间窗口容错策略如果某一步失败备选方案是什么例如“开发一个简单的待办事项应用”需要分解为创建项目结构 → 设计数据库模型 → 实现后端 API → 构建前端界面 → 编写测试 → 部署上线。每个子任务又可以进一步分解直到达到工具可以直接操作的粒度。3. 动态执行与状态监控在执行过程中Agent 需要持续评估进展当前步骤是否按预期进行中间结果是否符合质量要求检测异常工具调用是否失败返回结果是否异常调整策略根据环境反馈决定是继续、重试、回退还是切换方法资源管理监控上下文长度、工具调用次数、执行时间等资源消耗这种持续判断不是简单的“if-else”逻辑而是基于对任务目标、当前状态和环境反馈的综合评估。例如当代码执行报错时Agent 需要判断这是语法错误直接修复、逻辑错误重新设计算法还是环境配置问题检查依赖。它有一个独特能力叫内部思考在采取实际行动之前先规划和推演。这个过程不改变外部环境却能显著提升后续行动质量。之所以有效是因为预训练让模型习得了人类知识中沉淀下来的逻辑规则——数学定律、因果关系、问题分解策略。与传统 RL Agent 的盲目随机探索相比今天的 LLM Agent 是在结构化知识体系上展开搜索。4.1 模型即 Agent编排没有消失只是搬了位置“模型即 Agent”Model as Agent是当前最受关注的范式先进模型通过后训练尤其是强化学习把工具调用能力内化为原生能力何时调用、调哪个、传什么参数都由模型自己决定。这里有一个流传很广的误解需要澄清关键在于分清两件事的归属强化学习写进参数的是决策何时调用工具、调用哪个、传什么参数、拿到结果后是否继续、如何把几十上百次调用串成连贯推理。工具本身及其执行仍在模型之外web_search、code_runner的真实实现、代码沙盒环境、调用的发起与结果回传都由 Agent 框架或 API 内置工具提供。换句话说编排循环没有消失而是从客户端搬到了服务端决策权交给了模型。一些模型把托管工具跑在服务端脚本引擎里另一些把网络搜索和代码解释器做成 API 内置工具客户端不必再自己搭“搜索—阅读—分析”的编排框架。这类模型带来的实际收益中最容易被低估的是长链稳定性。多数模型在几十次工具调用之后就开始退化重复调用同一个工具、遗忘早期约束、把中间结论当成最终答案。而面向长周期 Agent 负载优化的模型能连续执行两三百次调用并保持思考一致性。对于需要跑几小时的任务这个差异比单点准确率重要得多。另一个值得注意的产品级设计是意图澄清。面对“搜索最近一个月的比特币走势做技术分析”这样的请求成熟的实现不会立刻动手而是先问清楚偏好哪个数据源需要哪些技术指标这个小动作的意义在于它把“用户说了什么”和“用户真正想要什么”之间的差距在任务执行之前就填平了——否则代价是几十次工具调用之后的全盘重做。工具调用格式上也有渐进的改良比如自由格式工具调用允许模型直接向工具发送原始文本一段 Python 代码、一条 SQL省掉 JSON 转义的麻烦。要清楚这是 API 参数格式的演进不是模型架构的革新客户端“检测调用 → 执行 → 回传结果”的循环逻辑一点没变。4.2 苦涩的教训方向认同节奏务实如果模型持续变强今天这些 Harness 会不会最终被模型吃掉Rich Sutton 在《苦涩的教训》里回顾了 AI 研究七十年反复上演的一幕研究者一次次把自己对领域的理解编码进系统短期见效长期总是输给能随算力与数据规模持续扩展的通用方法——搜索与学习。按这个标准衡量Harness 里的约束、验证与纠正有多少属于注定被内化的“人类先验”务实的立场是方向认同节奏务实。方向上模型确实会持续吃掉 Harness——工具调用、长程规划都曾靠外部编排如今已是原生能力。但节奏上这个“吃”的过程比想象中慢得多训练以月为单位而模型不可能一次内化真实业务里全部的约束与偏好。模型此刻的能力边界就是 Harness 此刻的价值所在。所以 Harness 工程不是对苦涩教训的抵抗而是这一教训在工程时间尺度上的实践模型还做不稳的Harness 先补上模型每内化一层Harness 就卸下一层转而兜底新的能力前沿。4.3 Agent 的行为如何改变三条时间尺度不同的路径行为改变不只发生在训练阶段。按更新发生的位置和持续时间可以分成三条互补路径路径主要载体更新特性典型手段任务内适应当前上下文即时、低成本任务结束不自动保留示例、状态、检索结果外部产物更新知识、指令、程序跨任务持久、可审计依赖检索或工具调用知识文档、Prompt / Skill、Harness 代码参数更新模型权重高维能力、泛化广训练与回归成本高SFT、偏好训练、RL三者不是互斥分类而是不同时间尺度上的协同机制上下文负责临场适应外部产物负责可控积累参数负责内化那些难以显式表达的能力医疗影像理解、自然语言风格、隐式决策策略。这个划分在实践中有直接用途遇到一个失败案例先问它属于哪一层。如果是“模型不知道这条业务规则”写文档或改 Prompt 就够了不必训练如果是“模型总把中文引号写成英文引号”这种风格问题反复加 Prompt 约束的性价比就远低于一次针对性的后训练。五、眼睛上下文的五个组成部分从 API 视角看每次调用 LLM 时的上下文由五部分构成系统提示词System Prompt由开发者编写整个对话中保持不变相当于 Agent 的岗位说明书——定义身份、权限和行为准则。跨会话保存的用户记忆和动态注入的环境状态通常也放在这里。工具定义Tool Definitions声明可用工具的名称、功能描述和参数格式。没有它Agent 无法识别和调用任何工具。用户消息User Messages来自用户的输入也可能包含通过 RAG 检索引入的外部知识。模型回复Assistant Messages最多包含三部分——思考过程reasoning、文本内容content、工具调用请求tool_calls。三者不一定同时出现决定调工具时通常只有 reasoning tool_calls给最终答案时通常只有 reasoning content。工具执行结果Tool Results框架执行工具后返回的结果是下一步思考的直接依据。前两项是静态前缀后三项是随交互不断增长的动态消息历史。这个划分不是形式上的整理而是后面所有性能优化尤其是缓存的基础。5.1 消融实验每个组件缺了会怎样验证组件是否必要最直接的方法是消融实验Ablation Study——逐一去掉一个组件看系统还能不能工作。系统提示词不参与消融因为没有它 Agent 连角色认知都没有测试没有意义。配置工具定义思考过程历史记录工具结果结果完整基线✓✓✓✓正常工作无工具定义✗✓✓✓完全无法调用工具无思考过程✓✗✓✓决策前后不连贯无历史记录✓✓✗✓重复已做过的操作无工具结果✓✓✓✗盲目循环永不收敛四种退化模式各有清晰的机理工具定义是行动能力的前提工具结果是闭环控制的关键缺了它 Agent 就在开环状态下“盲打”思考过程保留了此前决策的理由避免前后矛盾历史消息防止冗余操作和重复犯错。结论可以浓缩成一句话Agent 只能基于它看到的信息做决策。上下文缺一块决策能力就掉一块而且掉法各不相同——这也是排查线上问题时的一份速查表看到 Agent 无限循环先检查工具结果是否真的回到了上下文看到它重复操作先检查历史是否被截断得太狠。六、ReAct 循环轨迹如何驱动任务推进ReActReasoning Acting是把 LLM、上下文和工具串起来的核心机制。名字里只有思考和行动两个词实际循环有三个环节思考当前该做什么 → 调用工具行动 → 观察返回结果并继续思考。“想 → 做 → 看”不断重复直到任务完成。轨迹trajectory是这个过程中不断积累的消息历史用户消息、模型回复思考过程 工具调用、工具执行结果。于是有Agent 的上下文 静态前缀 轨迹最小运行骨架如下伪代码用于说明机制而非直接运行trajectory[user_request]repeat:contextstable_prefixtrajectory decisionModel(context)trajectory.append(decision)ifdecision has no tool call:returndecision.answerforcallindecision.tool_calls:# 相互独立的调用可以并行validated_callHarness.validate(call)observationEnvironment.execute(validated_call)trajectory.append(observation)职责分工在这段骨架里一目了然Model 只决定下一步Harness 组装上下文、校验并执行工具Environment 产生真实状态变化和观察。以一个多币种收入汇总任务为例跑完之后轨迹里保存的数据大致是这样[ {role: user, content: Q1 2.5M 美元Q2 2.1M 欧元Q3 1.8M 英镑Q4 380M 日元 计算年度总收入和季度平均收入}, # 第 1 轮模型看到上述轨迹后生成响应 {role: assistant, reasoning: 需要将所有货币转换为 USD..., content: , tool_calls: [convert_currency(2100000, EUR→USD), convert_currency(1800000, GBP→USD), convert_currency(380000000, JPY→USD)]}, {role: tool, content: EUR-USD: 2282608.70}, {role: tool, content: GBP-USD: 2278481.01}, {role: tool, content: JPY-USD: 2541806.02}, # 第 2 轮模型看到完整轨迹含工具结果 {role: assistant, reasoning: 已获得转换结果现在汇总计算..., content: , tool_calls: [code_interpreter(total 2500000 2282608.70 ...)]}, {role: tool, content: Total: $9,602,895.73 Average: $2,400,723.93}, # 第 3 轮生成最终答案 {role: assistant, reasoning: 所有计算完成总结结果..., content: 总收入 $9,602,895.73季度均值 $2,400,723.93} ]注意轨迹里看不到系统提示词和工具定义——它们作为静态前缀每次调用时自动拼在轨迹前面。三轮迭代、四次工具调用任务结束。这种“不断追加”的设计有两个直接好处。一是每次调用模型都能看到完整轨迹它清楚任务进行到哪一步、试过什么、得到了什么二是轨迹结构化之后系统易于解释和调试用户消息、模型回复、工具结果彼此分明。更长远的价值在于大量轨迹可以用来分析行为模式、优化决策路径、改进工具设计还能沉淀进知识库或用于强化学习形成从经验中学习的闭环。**一个必须提前知道的代价**由于每轮都要把完整上下文重新送进模型累计的缓存读取量随轮数近似二次方增长。一个 200 轮的任务其上下文吞吐远不是 20 轮任务的 10 倍。这正是下一篇要展开的上下文压缩、前缀稳定与子 Agent 隔离等技术的动机所在。七、Harness 工程模型之外的竞争力现在回到开头那条沟。基本机制是有效的但脆弱点非常明确幻觉、选错工具、错误后无法自我恢复。Harness 工程要解决的正是这些。生产形态下的完整组成可以写成Agent Model Harness Harness 上下文管理 工具接口 约束 验证 纠正 Agent ↔ Environment最小 Demo 只需要 Model 加上“能构造上下文、能暴露工具”的 Harness生产系统要在同一边界内加入三层保障机制。以退款 Agent 为例政策放进上下文权限和金额规则约束调用数据库状态验证结果超时时重试或回退。五个要素的职责与核心原则如下要素职责与核心原则实际例子Context上下文提供感知信息信息要充分让每个决策点都有足够依据系统提示词、知识库、Agent 状态栏、旁路查询Tools工具接口提供观察与行动手段接口要清晰命名直观、参数有例子、边界有说明MCP 工具、代码解释器、搜索工具Constrain约束设定行为边界故障安全默认值能力默认关闭、必须显式开放每个工具默认需要用户授权才能执行Verify验证自动判断结果对错安全检查只看结构化数据不看模型自由生成的文本Linter、类型系统、工具调用结果校验Correct纠正自动修正或回退确认无法恢复前不暴露中间态静默重试、接续生成、连续失败熔断转人工Verify 那一条值得单独强调安全检查只看结构化数据比如工具返回的 JSON 字段不看模型自由生成的文本。原因很简单——后者可能已经被提示注入操纵。让被攻击的模型自己汇报“我没有被攻击”是一种结构性失效。控制循环的骨架observationEnvironment.observe()trajectory[observation]whileTrue:actionsModel(Harness.build_context(trajectory))iflen(actions)0:breakallowed_actionsHarness.constrain(actions)observationEnvironment.apply(allowed_actions)ifnotHarness.verify(Environment):observationHarness.correct(Environment)trajectory.append(allowed_actions,observation)五个功能构成闭环上下文与工具让 Agent“能做事”约束预防错误、验证发现偏差、纠正形成闭环三者共同让 Agent“不做错事”。两类功能的重要性是不对称的。早期框架主要关注前者给模型工具和上下文让它能干活。生产级系统的重心已经转向后者。以 Claude Code 为例它的 Harness 里绝大部分代码是约束、验证与纠正而不是工具本身流程状态管理、多层上下文压缩、权限分类、熔断器错误连续发生时自动断开重试就像保险丝跳闸、错误恢复捕获异常、回滚到上一稳定状态、重试或交还人类。行业正在从“能做事”转向“可靠地做事”这就是 Harness 成为核心竞争力的原因。7.1 五层递进从提示工程到 Graph 工程AI 应用工程的演进有一条清晰的弧线而且这五层是层层包含而非互相替代的关系提示工程Prompt Engineering优化输入给模型的自然语言指令。上下文工程Context Engineering系统性管理模型能看到的所有信息——系统指令、工具定义、对话历史、外部知识。Harness 工程从“模型能看到什么”扩展到“Agent 如何组织模型运行并与环境交互”涵盖约束、验证、反馈循环和错误恢复。Loop 工程Loop Engineering从单次运行扩展到跨轮次的持续自主运转——谁来发现下一件该做的事、何时验证、何时才算真正完成。Graph 工程Graph Engineering把 Agent 循环、确定性程序和人工审批组织成显式执行图节点承担能力边规定路由与依赖结构化状态沿边传递并在关键边界处持久化。包含关系是提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程——单个 Agent 循环正是执行图中的一个节点。每一层都在前一层基础上扩展了工程师的关注范围。还有一个容易被忽略的规律实践在前命名在后。动态加载提示词的做法早于 Skill 这个词流行类似 Claude Code 的工具调用治理早于 harness 一词流行提议者—审核者式的双角色互查早于 loop engineering 流行。当一个术语成为行业共识它对应的问题往往已经在领先系统里被探索很久了。对企业级开发的启示是等术语普及再动手就已经落后一个周期。这条判断有硬证据支撑。LangChain 在 Terminal Bench 2.0评估 Agent 在终端环境完成复杂任务的基准上把得分从 52.8% 提升到 66.5%从榜单三十名开外跃入前五。改变的不是模型而是 Harness让 Agent 自动检查自己的执行结果、检测是否陷入重复循环、优化思考策略。7.2 三条核心原则保持简单。从最简单的方案开始只在确实必要时增加复杂度。直接的 API 调用优于复杂框架清晰的代码优于聪明的抽象——每多一层抽象都会成为日后调试时新的盲区。保持透明。明确展示规划步骤、执行日志和决策轨迹。这不只是为了调试方便也是用户建立信任的前提黑箱里的错误一旦发生外部观察者既无法定位也无法纠正。设计好 ACIAgent-Computer Interface。传统 API 从程序员视角设计ACI 强调从 Agent 视角设计命名和参数要直观容易误用的地方要让错误从设计上无法发生。SIM 卡的缺角让卡片只能朝一个方向插入微波炉门没关好就绝不加热——这种用设计消除错误的思路在制造业有个专门的名字叫防呆Poka-yoke源自丰田生产体系。为什么 ACI 这么关键因为模型与工具之间唯一的沟通通道就是接口本身。模糊的接口会被模型放大成系统性错误再强的模型也救不回来。八、编排模式工作流与自主 Agent编排模式决定上下文如何在 LLM 调用之间流动、工具如何被调度、执行路径是预设还是动态生成。经验一致指向同一个结论最成功的实现往往不是复杂框架而是简单、可组合的模式。合理的推进顺序是先考虑单次 LLM 调用——如果优化提示词和示例就能解决不要引入 Agent 系统需要多步骤且能清晰分解为固定子任务时用工作流只有需要动态决策和灵活路径时才用自主 Agent。要记住 Agent 系统本质上是用延迟和成本换任务性能这笔交换未必总是值得。8.1 工作流确定性编排工作流Workflow通过预定义的代码路径编排 LLM 和工具执行路径是确定的LLM 只在节点内部负责理解和生成。以订机票为例四个固定节点核实用户身份 → 搜索可用航班 → 完成付款 → 确认预订。每个节点内部可以用 LLM 理解自然语言需求但节点间的流转顺序由代码写死——系统不会在付款完成之前预订座位也不会在身份核实之前搜航班。两个核心优势严格的流程控制“付款前不能预订”这类业务规则由代码强制执行不依赖模型判断。安全性执行路径确定提示注入或模型犯错最多影响当前节点内部处理无法让 Agent 跳到不该执行的分支攻击面被限制在单个节点内。主要局限是缺乏变通。用户在付款环节临时想改签、航班突然取消需要推荐替代方案——预设流程没覆盖的情况只能走异常分支或交还人类。8.2 自主 Agent动态决策自主 Agent 的执行路径不预先定义而是根据环境反馈实时决定。同样是订机票用户说“帮我订下周三去上海的机票”Agent 自行决定先搜航班、发现需要登录于是先核实身份、再回来搜索、发现最便宜的航班要转机、主动问用户是否接受、用户说不要转机、于是调整搜索条件……它需要自主规划的能力还要能识别失败、调整策略而不是一出错就停。但自主不等于无限制必须设计明确的停止条件否则容易陷入死循环或过度执行。常见退出条件包括任务已完成、调用了最终输出工具、模型返回没有任何工具调用的响应、错误次数超限、达到最大轮数。自主 Agent 特别适合难以预测步骤数量的开放式问题修复真实代码仓库的 issue、像人一样操作图形界面、需要迭代搜索和分析的研究任务。代价是更高的成本和复合错误风险——每一步 95% 的正确率二十步之后只剩三分之一。因此部署前必须在沙盒充分测试设置护栏与监控并在关键决策点加入人机协作检查点。8.3 混合才是常态实践中两种模式不是二选一。关键的、有严格合规要求的流程用工作流保证可靠性需要灵活决策的部分切换到自主模式。成熟的可视化自动化平台通常允许在同一系统里同时使用工作流节点和自主 Agent 节点。关于框架选型一个务实的建议框架发展极快学会某个具体框架的 API 并不重要。选择时的关键考量不是框架本身多强大而是它能否用尽可能少的抽象层让你专注业务逻辑。轻量库适合快速原型生产级框架适合复杂自主任务可视化平台适合业务自动化和非技术团队多 Agent 编排框架适合团队式任务分解——按场景选不按热度选。九、护栏按“被绕过的难度”分三层护栏Guardrails是保障行为安全可控的分层防线既管数据隐私风险防止系统提示泄露也管声誉风险确保行为与品牌形象一致。单个护栏不可能提供足够保护多个专门护栏组合才能构建有韧性的系统。三层划分不是按请求处理的先后顺序而是按被绕过的难度——越靠下的层越不依赖模型自己的判断越难被一次成功的攻击穿透。9.1 上下文层管模型能看到什么在内容进入上下文之前拦截通常有四种机制相关性分类器标记偏离主题的查询比如编程助手收到“帝国大厦有多高”。安全分类器检测越狱和提示注入。两者的区别很关键——越狱是用户自己试图绕过安全限制提示注入是攻击者通过外部数据网页内容、文档间接操纵模型行为。内容审核标记有害或不当输入。规则保护黑名单、输入长度限制、正则过滤用于防范已知威胁。一个代表性的工业实践是宪法分类器Constitutional Classifiers核心机制有三点用自然语言规则生成合成训练数据来训练输入输出分类器把用户提问和模型回答放在一起联合判断有些回答单独看毫无问题只有对照提问才能发现是暗语两级筛查——先用极轻量的探针直接读取模型内部激活检查所有对话可疑的再交给更强分类器复审。两级设计的妙处在于第一级即使误报较多也不影响体验成本还大幅降低。但这一层有结构性上限处在同一个上下文里的 Agent很难判断自己是否已经被注入。所以它只能降低攻击成功率给不出保证。9.2 执行层管模型能做什么在动作真正生效之前验证。核心是工具风险评级按操作是否可逆、权限等级、财务影响为每个工具标注低 / 中 / 高风险高风险操作需额外审查或人工确认。关键在于这类复核必须由上下文之外的机制完成——独立的审查进程、最小权限凭证、沙盒隔离、人在回路。否则它会和被注入的 Agent 一起沦陷。返回给用户的回复本身也是一次动作因此输出检查同样属于这一层PII 过滤器审查输出中的身份证号、手机号等个人信息输出验证确保回复与品牌价值一致。9.3 数据层管世界最终能被改成什么样把“谁能对哪条数据做什么”交给一层稳定的、经过人类审查的机制强制执行数据库行级安全策略、约束与校验器、受控视图与存储过程以及由受信任运行时绑定、无法伪造的访问上下文。这一层的价值在于它不依赖上面两层是否正确即使提示注入得手、生成的代码完全漏写了权限判断越权操作仍会在数据层被拒绝。9.4 两个容易被忽视的实践细节误拒绝也是失败。为了降低危险请求被放行的概率模型可能同时拒绝一部分合法但形式敏感的任务——经过授权的安全测试、模型蒸馏研究都常被误伤。因此护栏评估不能只测“应当拒绝的请求是否被拦截”还要测“明确允许的请求是否能正常完成”。人在回路的两个触发条件。一是超过失败阈值为重试次数或操作次数设上限超限即升级人工。二是高风险操作敏感、不可逆、涉及大额资金的操作触发人工监督。在客户服务里这意味着升级人工客服在 Coding Agent 里意味着把控制权交还开发者。部署早期尤其重要它能帮你识别失败模式、发现边缘情况、建立健壮的评估周期。十、五个反复出现的设计模式下面五个模式会在 Agent 系统的各个层面反复出现值得提前建立索引。提议者—审核者Proposer-Reviewer。产出与评判由两个不共享上下文的角色分别承担评判方看到的是产物本身——渲染结果、测试输出、结构化的调用参数——而不是产出方的推理过程。它成立的前提是自审不可靠同一个上下文中的模型难以发现自己的盲区也很难判断自己是否已被注入。渐进式披露Progressive Disclosure。不把全部信息一次性放进上下文而是先给一份可检索的目录再按需加载细节。它同时优化两件事上下文预算与选择精度。Skill 的“元数据常驻、正文按需加载”是最典型形态。只增不改Append-only。状态以追加方式演进已写下的内容不回头修改。换来的是可缓存、可重放、可审计。它的性能形态就是前缀稳定性——改动越靠前作废的缓存越多。边界集 保留集Boundary Set Retention Set。任何一次修改都要同时在“它应当改变的那批样本”和“它不应当影响的那批样本”上验证。只测前者会把过拟合当成进步只测后者会把无效修改当成安全。最小 diff 可回滚。每次修改尽量小、带来源、可单独回滚让归因成为可能。有意思的是前面那三条更新路径任务内适应、外部产物更新、参数更新正好是按可回滚程度从高到低排列的。结语把认知锚在四个判断上第一Agent 大脑 眼睛 手脚三者缺一不可。消融实验给出的四种退化模式各不相同排查问题时可以直接当速查表用。第二扩展眼睛和手脚是模型固定时最主要的能力杠杆。通用性很大程度来自接口边界的扩大但这种扩大必须按需进行并配合权限控制和验证——否则扩大的是攻击面。第三Harness 是竞争力所在。模型能力正在商品化真正的差异在于围绕上下文和工具构建的约束、验证与纠正。同一个模型、不同 Harness基准分数差十几个百分点、排名差二十几位这已经不是理论推演。第四安全是架构问题不是上线前的补丁。护栏按被绕过的难度分为上下文层、执行层、数据层越往下越可靠。任何依赖“让模型自己检查自己”的方案都应该被视为只能降低概率、不能提供保证。留几个问题供思考如果只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文、还是更多工具——你会选哪个什么条件下选择会改变ReAct 循环里累计缓存读取量随轮数近似二次方增长如何降低这种增长“模型即 Agent”意味着模型在工具调用决策上越来越自主而 Harness 的重要性反而在增加。这两个趋势如何共存除了工具结果缺失还有哪些情况会导致 Agent 无限循环你会设计怎样的检测和终止机制如果要做一个航班订票客服系统你会选工作流还是自主 Agent有没有第三种答案下一篇进入 Harness 中最核心的组件上下文工程——从 API 消息结构讲到 KV Cache 的底层约束再到 Skills、状态栏与压缩策略。
尧图网络