1. 从一句判断说起为什么“harness 总比模型快一步”“harness 总比模型快一步”这句话第一次听到会觉得有点反直觉。模型不是整个系统的核心吗参数规模、推理能力、上下文长度这些才是决定 Agent 能不能干活的关键。但真正在一线搭过 Agent 系统的人大概率会点头。因为模型是“大脑”而 harness 是“身体、神经和反射弧”。大脑再聪明如果身体跟不上动作就是慢半拍。先把概念说清楚。Codex在这里指的是一类代码智能体coding agent的运行时形态它不只是“补全代码”而是能读文件、改文件、跑命令、看输出、再决定下一步的闭环系统。harness则是包裹在模型外面的那一层工程骨架任务编排、工具调用、上下文管理、状态持久化、错误恢复、权限控制、并发调度。Agent是最终呈现给用户的行为主体而GPT系列模型是驱动这个主体的推理引擎。Rust在这套体系里扮演的是高性能、低延迟、强类型的基础设施语言尤其适合做 harness 的底层实现。为什么说 harness 比模型快一步因为模型的能力提升是阶梯式的一次训练、一次发布能力上一个台阶然后停在那里。而 harness 的优化是连续的、每天都在发生的。同一个模型换一套更好的 harness任务成功率可能从 40% 拉到 70%。这不是玄学是工程现实。模型决定上限harness 决定你能不能摸到那个上限。这篇文章适合谁看如果你正在做 AI Agent 开发尤其是涉及 Codex 类代码智能体、工具调用编排、Rust 高性能后端那这篇就是写给你的。如果你只是好奇 Agent 和 harness 到底有什么区别我也会用生活化的方式讲明白。全文基于常见工程实践展开涉及具体参数和步骤的地方我会说明这是基于一线经验的合理补全不是某个特定产品的官方文档。2. 核心概念拆解harness、Agent、模型到底谁管谁2.1 用“赛车”类比理解三层关系很多人把 Agent 和模型混为一谈觉得“用了 GPT 就是 Agent”。这就像说“装了发动机就是赛车”。发动机是模型赛车手是 Agent 的决策逻辑而 harness 是底盘、变速箱、刹车、方向盘助力、轮胎管理这一整套东西。模型负责“想”harness 负责“让想的事情能稳定发生”。Agent 是这两者结合后对外表现出的行为。你问 Agent“帮我重构这个模块”Agent 决定要读哪些文件、改哪几行、跑什么测试这是决策层harness 负责真正去读文件、真正去执行命令、真正把结果喂回给模型这是执行层。提示很多团队初期把大量精力花在换模型上结果发现效果提升有限。真正卡脖子的往往是 harness 里的上下文裁剪策略、工具返回格式、错误重试逻辑。2.2 harness 和 Agent 的区别到底在哪热搜词里有人问“harness 和 agent 区别”这个问题很典型。简单说Agent 是角色harness 是舞台和道具。Agent 是一个会做决策的实体它有目标、有记忆、有策略。harness 是支撑这个实体运转的工程系统它不关心“为什么要做”只关心“怎么可靠地做完”。举个例子。Agent 决定“我要搜索代码库里所有调用旧 API 的地方”。harness 要做的是把搜索工具注册好、限制搜索范围、处理超时、把结果截断到模型能接受的 token 数、如果搜索失败要返回结构化错误而不是一堆堆栈。Agent 看到的是“搜索完成找到 12 处”harness 在背后处理了 20 个细节。所以当你看到“deepseek harness”“harness engineering”这类词它指的往往不是模型本身而是围绕模型构建的那套工程体系。模型可以换harness 的积累是留下来的。2.3 为什么 Rust 在这个位置频繁出现热搜里“rust”“基于 rust 语言 ai agent”“tauri rust 开发桌面应用”这些词不是偶然。harness 对性能的要求很实际工具调用要快、上下文序列化要快、并发任务调度要稳、内存占用要可控。Rust 没有 GC 停顿所有权模型让并发安全在编译期就能保证这对长时间运行的 Agent 服务很关键。我用 Rust 写过工具调用的调度层最直观的感受是延迟曲线很平。同样的并发量用带 GC 的语言写P99 延迟会周期性抖动因为 GC 在扫。Rust 不会它的延迟是可预测的。对于 Agent 这种“模型推理已经够慢了工程层不能再添乱”的场景可预测性比峰值性能更重要。当然Rust 不是唯一选择。Python 做原型快TypeScript 生态好。但如果你的 harness 要长期跑、要高并发、要嵌入到桌面应用比如 TauriRust 的收益会越来越明显。3. harness 的核心模块与实操要点3.1 上下文管理最容易被低估的“快一步”模型再强上下文塞错了也白搭。harness 里最影响效果的不是工具数量而是上下文组装策略。我见过太多项目工具写了几十个但每次调用都把整个文件内容塞进去结果 token 爆了模型反而变笨。实操上上下文管理要分三层系统层放角色定义和硬约束任务层放当前目标和进度工具层放最近几次调用的结果。关键是工具层要做滚动窗口不是无限追加。常见做法是保留最近 N 次工具调用N 根据模型上下文窗口反推。假设模型上下文 128k token系统层占 2k任务层占 3k留给工具结果和对话历史的大概 120k。一次文件读取平均 2k token那最多保留 60 次。但实际不能这么算因为模型还需要空间生成回复。保守一点工具结果控制在 60k 以内也就是 30 次左右。超过就做摘要或者丢弃最旧的。注意丢弃不是简单删掉。更好的做法是把旧结果压缩成一句话摘要比如“已读取 auth.rs包含 3 个函数”保留语义锚点避免模型完全失忆。3.2 工具调用的错误处理别让一次失败毁掉整个任务Agent 跑长任务时工具调用失败是常态。网络抖动、文件被占用、命令超时、权限不足这些都会发生。harness 的错误处理决定了 Agent 是“摔一跤爬起来”还是“直接躺平”。我的经验是分三级处理。可重试错误超时、临时锁自动重试 2 到 3 次退避间隔用指数增长比如 1s、2s、4s。可降级错误某个工具不可用返回结构化提示让模型换工具或换路径。致命错误权限拒绝、路径不存在直接终止当前子任务把控制权交回模型让它决定下一步。这里有个细节错误信息不要直接抛堆栈给模型。堆栈又长又没信息量模型看了也懵。harness 应该把错误翻译成模型能理解的自然语言比如“读取 /etc/config 失败原因是权限不足建议检查文件权限或换用可读路径”。这一层翻译做得好Agent 的自恢复能力会明显提升。3.3 状态持久化Agent 不能是“金鱼记忆”长任务跑几个小时中间进程重启、网络断开、用户暂停这些都要能恢复。harness 需要把 Agent 的状态定期落盘。状态包括当前任务目标、已完成步骤、待办步骤、最近工具结果、关键变量。落盘格式用 JSON 或 MessagePack 都行关键是可读、可版本兼容。我倾向于 JSON因为调试方便出问题能直接看。落盘频率不要太高每次工具调用后落一次就够太频繁 IO 会成为瓶颈。恢复的时候要注意不是简单加载状态就继续。要先校验状态和当前环境是否一致比如文件是否还在、依赖是否满足。不一致就触发重新规划而不是硬着头皮往下跑。4. 从零搭一个最小可用 harness 的实操过程4.1 环境准备与依赖选择假设我们用 Rust 做一个最小 harness目标是支持 Codex 类代码任务读文件、改文件、跑命令、看结果。依赖选择上异步运行时用 tokio序列化用 serde命令行执行用 tokio::processHTTP 调用用 reqwest。这些是 Rust 生态里最稳的组合。[dependencies] tokio { version 1, features [full] } serde { version 1, features [derive] } serde_json 1 reqwest { version 0.12, features [json] }安装 Rust 本身用 rustup这个没什么好说的。需要注意的是如果你在 Windows 上开发建议用 WSL2 或者直接 Linux 环境因为很多工具调用涉及 shell 命令跨平台差异会带来额外调试成本。4.2 定义工具接口与注册机制harness 的工具层要统一接口。每个工具至少要有名称、描述、参数 schema、执行函数、超时配置。用 Rust 的 trait 来抽象#[async_trait] trait Tool { fn name(self) - str; fn description(self) - str; fn schema(self) - serde_json::Value; async fn execute(self, args: serde_json::Value) - ResultString, ToolError; }注册机制用 HashMap 存工具名到 trait object 的映射。模型返回工具调用请求时harness 根据名称查找、校验参数、执行、把结果格式化后返回。这里的关键是参数校验要在执行前做不要等执行到一半才发现参数错了。4.3 上下文组装与模型交互循环核心循环是这样的组装上下文 - 调用模型 - 解析响应 - 如果是工具调用就执行 - 把结果追加到上下文 - 再调用模型 - 直到模型返回最终答案或达到最大轮次。最大轮次要设上限我一般设 50 轮。超过就强制终止返回当前进度。不设上限的后果是 Agent 可能陷入死循环烧 token 还不出结果。上下文组装时系统提示词要写清楚你是一个代码助手你可以使用以下工具每次只能调用一个工具调用后等待结果。这些约束看起来简单但能显著减少模型的乱来。4.4 并发与超时控制工具调用可以并发但要有度。读文件可以并发写文件必须串行跑命令要看命令本身是否幂等。harness 里用一个信号量控制并发数我一般设 4 到 8。太高会导致资源争抢太低浪费等待时间。超时控制分两层单次工具调用超时默认 30 秒整个任务超时默认 10 分钟。超时后不是直接杀进程而是先发取消信号给工具清理的机会再强制终止。5. 常见问题与排查技巧实录5.1 模型不调用工具只输出文本这是最常见的问题。原因通常有三个工具描述不清楚、系统提示词没强调工具使用、模型本身对工具调用支持不好。排查顺序是先看工具 schema 是否规范再看系统提示词是否明确要求“必须使用工具完成任务”最后考虑换模型或调整 temperature。我遇到过工具描述写得太抽象模型理解不了什么时候用。后来把描述改成“当需要读取文件内容时使用此工具参数 path 是文件绝对路径”调用率立刻上来了。5.2 工具调用参数格式错误模型返回的 JSON 参数经常有细微错误比如该传字符串传了数字、该传数组传了对象。harness 要做宽容解析能自动转换就转换不能转换就返回明确错误让模型重试。不要直接 panic那会让整个任务崩掉。5.3 上下文爆炸导致模型变傻前面提过工具结果无限追加是主因。解决办法是滚动窗口加摘要。另外大文件读取要分块不要一次读整个文件。harness 可以在读取工具里加行数限制默认读前 200 行需要更多让模型显式请求。5.4 任务跑一半卡住卡住的原因可能是模型在等一个永远不会返回的工具结果或者工具在等一个永远不会来的输入。harness 要有心跳检测超过一定时间没有进展就触发超时把控制权交回模型并提示“上一步操作超时请换一种方式”。下面这张表是我整理的高频问题速查问题现象可能原因排查动作解决方向模型不调用工具描述不清、提示词弱检查 schema 和系统提示改描述、加强约束参数格式错误模型输出不稳定看原始返回 JSON宽容解析加错误回传上下文爆炸结果无限追加统计 token 增长滚动窗口加摘要任务卡住工具无响应看最后工具调用加心跳和超时恢复后行为异常状态与环境不一致校验文件和依赖触发重新规划提示排查时先看 harness 日志不要一上来就怀疑模型。我踩过的坑里八成问题出在工程层模型本身没毛病。6. 性能优化与扩展方向6.1 减少模型调用次数的技巧模型调用是最大的延迟来源。harness 可以通过批量工具调用来减少轮次。比如模型一次返回多个工具调用请求harness 并发执行后一起返回结果。这要求模型支持并行工具调用GPT 系列较新版本是支持的。另一个技巧是缓存。相同参数的相同工具调用在一定时间窗口内直接返回缓存结果。读文件这种幂等操作特别适合缓存。但写操作绝对不能缓存否则会出大问题。6.2 harness 的可观测性建设Agent 跑在生产环境没有可观测性就是黑盒。至少要记录每次模型调用的输入输出 token 数、每次工具调用的耗时和结果状态、任务整体轮次和耗时。这些数据用结构化日志输出方便后续分析。我用过最简单的方案是每次调用写一行 JSON 日志然后用脚本聚合。复杂一点可以接 OpenTelemetry但初期没必要先把日志打全。6.3 从单 Agent 到多 Agent 的扩展单 Agent 跑通后自然会想多 Agent 协作。但多 Agent 的复杂度不是线性增长是指数增长。通信、状态同步、冲突解决每一个都是坑。我的建议是先把单 Agent 的 harness 做扎实再考虑拆分。如果一定要拆先从“规划 Agent 执行 Agent”这种简单分工开始。规划 Agent 只负责拆任务执行 Agent 只负责干活两者通过 harness 里的任务队列通信。这样职责清晰出问题也好定位。7. 一些个人体会Rust 写 harness 的初期成本确实比 Python 高编译报错多、生命周期要理清楚。但一旦跑起来那种稳定感是值得的。我有个服务连续跑了三个月没重启内存曲线平的像一条直线。换成带 GC 的语言我可能每周都要看一眼内存。Codex 类 Agent 的竞争到最后不是比谁的模型大是比谁的 harness 更懂任务、更懂错误、更懂恢复。模型会越来越强但 harness 的工程积累是每天都要做的功课。这句话我越用越觉得对harness 总比模型快一步因为模型在等下一次训练而 harness 每天都在进化。最后分享一个小技巧给你的 harness 加一个“干跑模式”不真正执行工具只打印将要执行什么。调试复杂任务时这个模式能帮你快速看清 Agent 的决策路径比看日志高效得多。 
长河君 · 2026/10/27 18:24:08 · 阅读 1.2k AI Agent开发实战：基于Rust的harness工程化与性能优化
1. 从一句判断说起为什么“harness 总比模型快一步”“harness 总比模型快一步”这句话第一次听到会觉得有点反直觉。模型不是整个系统的核心吗参数规模、推理能力、上下文长度这些才是决定 Agent 能不能干活的关键。但真正在一线搭过 Agent 系统的人大概率会点头。因为模型是“大脑”而 harness 是“身体、神经和反射弧”。大脑再聪明如果身体跟不上动作就是慢半拍。先把概念说清楚。Codex在这里指的是一类代码智能体coding agent的运行时形态它不只是“补全代码”而是能读文件、改文件、跑命令、看输出、再决定下一步的闭环系统。harness则是包裹在模型外面的那一层工程骨架任务编排、工具调用、上下文管理、状态持久化、错误恢复、权限控制、并发调度。Agent是最终呈现给用户的行为主体而GPT系列模型是驱动这个主体的推理引擎。Rust在这套体系里扮演的是高性能、低延迟、强类型的基础设施语言尤其适合做 harness 的底层实现。为什么说 harness 比模型快一步因为模型的能力提升是阶梯式的一次训练、一次发布能力上一个台阶然后停在那里。而 harness 的优化是连续的、每天都在发生的。同一个模型换一套更好的 harness任务成功率可能从 40% 拉到 70%。这不是玄学是工程现实。模型决定上限harness 决定你能不能摸到那个上限。这篇文章适合谁看如果你正在做 AI Agent 开发尤其是涉及 Codex 类代码智能体、工具调用编排、Rust 高性能后端那这篇就是写给你的。如果你只是好奇 Agent 和 harness 到底有什么区别我也会用生活化的方式讲明白。全文基于常见工程实践展开涉及具体参数和步骤的地方我会说明这是基于一线经验的合理补全不是某个特定产品的官方文档。2. 核心概念拆解harness、Agent、模型到底谁管谁2.1 用“赛车”类比理解三层关系很多人把 Agent 和模型混为一谈觉得“用了 GPT 就是 Agent”。这就像说“装了发动机就是赛车”。发动机是模型赛车手是 Agent 的决策逻辑而 harness 是底盘、变速箱、刹车、方向盘助力、轮胎管理这一整套东西。模型负责“想”harness 负责“让想的事情能稳定发生”。Agent 是这两者结合后对外表现出的行为。你问 Agent“帮我重构这个模块”Agent 决定要读哪些文件、改哪几行、跑什么测试这是决策层harness 负责真正去读文件、真正去执行命令、真正把结果喂回给模型这是执行层。提示很多团队初期把大量精力花在换模型上结果发现效果提升有限。真正卡脖子的往往是 harness 里的上下文裁剪策略、工具返回格式、错误重试逻辑。2.2 harness 和 Agent 的区别到底在哪热搜词里有人问“harness 和 agent 区别”这个问题很典型。简单说Agent 是角色harness 是舞台和道具。Agent 是一个会做决策的实体它有目标、有记忆、有策略。harness 是支撑这个实体运转的工程系统它不关心“为什么要做”只关心“怎么可靠地做完”。举个例子。Agent 决定“我要搜索代码库里所有调用旧 API 的地方”。harness 要做的是把搜索工具注册好、限制搜索范围、处理超时、把结果截断到模型能接受的 token 数、如果搜索失败要返回结构化错误而不是一堆堆栈。Agent 看到的是“搜索完成找到 12 处”harness 在背后处理了 20 个细节。所以当你看到“deepseek harness”“harness engineering”这类词它指的往往不是模型本身而是围绕模型构建的那套工程体系。模型可以换harness 的积累是留下来的。2.3 为什么 Rust 在这个位置频繁出现热搜里“rust”“基于 rust 语言 ai agent”“tauri rust 开发桌面应用”这些词不是偶然。harness 对性能的要求很实际工具调用要快、上下文序列化要快、并发任务调度要稳、内存占用要可控。Rust 没有 GC 停顿所有权模型让并发安全在编译期就能保证这对长时间运行的 Agent 服务很关键。我用 Rust 写过工具调用的调度层最直观的感受是延迟曲线很平。同样的并发量用带 GC 的语言写P99 延迟会周期性抖动因为 GC 在扫。Rust 不会它的延迟是可预测的。对于 Agent 这种“模型推理已经够慢了工程层不能再添乱”的场景可预测性比峰值性能更重要。当然Rust 不是唯一选择。Python 做原型快TypeScript 生态好。但如果你的 harness 要长期跑、要高并发、要嵌入到桌面应用比如 TauriRust 的收益会越来越明显。3. harness 的核心模块与实操要点3.1 上下文管理最容易被低估的“快一步”模型再强上下文塞错了也白搭。harness 里最影响效果的不是工具数量而是上下文组装策略。我见过太多项目工具写了几十个但每次调用都把整个文件内容塞进去结果 token 爆了模型反而变笨。实操上上下文管理要分三层系统层放角色定义和硬约束任务层放当前目标和进度工具层放最近几次调用的结果。关键是工具层要做滚动窗口不是无限追加。常见做法是保留最近 N 次工具调用N 根据模型上下文窗口反推。假设模型上下文 128k token系统层占 2k任务层占 3k留给工具结果和对话历史的大概 120k。一次文件读取平均 2k token那最多保留 60 次。但实际不能这么算因为模型还需要空间生成回复。保守一点工具结果控制在 60k 以内也就是 30 次左右。超过就做摘要或者丢弃最旧的。注意丢弃不是简单删掉。更好的做法是把旧结果压缩成一句话摘要比如“已读取 auth.rs包含 3 个函数”保留语义锚点避免模型完全失忆。3.2 工具调用的错误处理别让一次失败毁掉整个任务Agent 跑长任务时工具调用失败是常态。网络抖动、文件被占用、命令超时、权限不足这些都会发生。harness 的错误处理决定了 Agent 是“摔一跤爬起来”还是“直接躺平”。我的经验是分三级处理。可重试错误超时、临时锁自动重试 2 到 3 次退避间隔用指数增长比如 1s、2s、4s。可降级错误某个工具不可用返回结构化提示让模型换工具或换路径。致命错误权限拒绝、路径不存在直接终止当前子任务把控制权交回模型让它决定下一步。这里有个细节错误信息不要直接抛堆栈给模型。堆栈又长又没信息量模型看了也懵。harness 应该把错误翻译成模型能理解的自然语言比如“读取 /etc/config 失败原因是权限不足建议检查文件权限或换用可读路径”。这一层翻译做得好Agent 的自恢复能力会明显提升。3.3 状态持久化Agent 不能是“金鱼记忆”长任务跑几个小时中间进程重启、网络断开、用户暂停这些都要能恢复。harness 需要把 Agent 的状态定期落盘。状态包括当前任务目标、已完成步骤、待办步骤、最近工具结果、关键变量。落盘格式用 JSON 或 MessagePack 都行关键是可读、可版本兼容。我倾向于 JSON因为调试方便出问题能直接看。落盘频率不要太高每次工具调用后落一次就够太频繁 IO 会成为瓶颈。恢复的时候要注意不是简单加载状态就继续。要先校验状态和当前环境是否一致比如文件是否还在、依赖是否满足。不一致就触发重新规划而不是硬着头皮往下跑。4. 从零搭一个最小可用 harness 的实操过程4.1 环境准备与依赖选择假设我们用 Rust 做一个最小 harness目标是支持 Codex 类代码任务读文件、改文件、跑命令、看结果。依赖选择上异步运行时用 tokio序列化用 serde命令行执行用 tokio::processHTTP 调用用 reqwest。这些是 Rust 生态里最稳的组合。[dependencies] tokio { version 1, features [full] } serde { version 1, features [derive] } serde_json 1 reqwest { version 0.12, features [json] }安装 Rust 本身用 rustup这个没什么好说的。需要注意的是如果你在 Windows 上开发建议用 WSL2 或者直接 Linux 环境因为很多工具调用涉及 shell 命令跨平台差异会带来额外调试成本。4.2 定义工具接口与注册机制harness 的工具层要统一接口。每个工具至少要有名称、描述、参数 schema、执行函数、超时配置。用 Rust 的 trait 来抽象#[async_trait] trait Tool { fn name(self) - str; fn description(self) - str; fn schema(self) - serde_json::Value; async fn execute(self, args: serde_json::Value) - ResultString, ToolError; }注册机制用 HashMap 存工具名到 trait object 的映射。模型返回工具调用请求时harness 根据名称查找、校验参数、执行、把结果格式化后返回。这里的关键是参数校验要在执行前做不要等执行到一半才发现参数错了。4.3 上下文组装与模型交互循环核心循环是这样的组装上下文 - 调用模型 - 解析响应 - 如果是工具调用就执行 - 把结果追加到上下文 - 再调用模型 - 直到模型返回最终答案或达到最大轮次。最大轮次要设上限我一般设 50 轮。超过就强制终止返回当前进度。不设上限的后果是 Agent 可能陷入死循环烧 token 还不出结果。上下文组装时系统提示词要写清楚你是一个代码助手你可以使用以下工具每次只能调用一个工具调用后等待结果。这些约束看起来简单但能显著减少模型的乱来。4.4 并发与超时控制工具调用可以并发但要有度。读文件可以并发写文件必须串行跑命令要看命令本身是否幂等。harness 里用一个信号量控制并发数我一般设 4 到 8。太高会导致资源争抢太低浪费等待时间。超时控制分两层单次工具调用超时默认 30 秒整个任务超时默认 10 分钟。超时后不是直接杀进程而是先发取消信号给工具清理的机会再强制终止。5. 常见问题与排查技巧实录5.1 模型不调用工具只输出文本这是最常见的问题。原因通常有三个工具描述不清楚、系统提示词没强调工具使用、模型本身对工具调用支持不好。排查顺序是先看工具 schema 是否规范再看系统提示词是否明确要求“必须使用工具完成任务”最后考虑换模型或调整 temperature。我遇到过工具描述写得太抽象模型理解不了什么时候用。后来把描述改成“当需要读取文件内容时使用此工具参数 path 是文件绝对路径”调用率立刻上来了。5.2 工具调用参数格式错误模型返回的 JSON 参数经常有细微错误比如该传字符串传了数字、该传数组传了对象。harness 要做宽容解析能自动转换就转换不能转换就返回明确错误让模型重试。不要直接 panic那会让整个任务崩掉。5.3 上下文爆炸导致模型变傻前面提过工具结果无限追加是主因。解决办法是滚动窗口加摘要。另外大文件读取要分块不要一次读整个文件。harness 可以在读取工具里加行数限制默认读前 200 行需要更多让模型显式请求。5.4 任务跑一半卡住卡住的原因可能是模型在等一个永远不会返回的工具结果或者工具在等一个永远不会来的输入。harness 要有心跳检测超过一定时间没有进展就触发超时把控制权交回模型并提示“上一步操作超时请换一种方式”。下面这张表是我整理的高频问题速查问题现象可能原因排查动作解决方向模型不调用工具描述不清、提示词弱检查 schema 和系统提示改描述、加强约束参数格式错误模型输出不稳定看原始返回 JSON宽容解析加错误回传上下文爆炸结果无限追加统计 token 增长滚动窗口加摘要任务卡住工具无响应看最后工具调用加心跳和超时恢复后行为异常状态与环境不一致校验文件和依赖触发重新规划提示排查时先看 harness 日志不要一上来就怀疑模型。我踩过的坑里八成问题出在工程层模型本身没毛病。6. 性能优化与扩展方向6.1 减少模型调用次数的技巧模型调用是最大的延迟来源。harness 可以通过批量工具调用来减少轮次。比如模型一次返回多个工具调用请求harness 并发执行后一起返回结果。这要求模型支持并行工具调用GPT 系列较新版本是支持的。另一个技巧是缓存。相同参数的相同工具调用在一定时间窗口内直接返回缓存结果。读文件这种幂等操作特别适合缓存。但写操作绝对不能缓存否则会出大问题。6.2 harness 的可观测性建设Agent 跑在生产环境没有可观测性就是黑盒。至少要记录每次模型调用的输入输出 token 数、每次工具调用的耗时和结果状态、任务整体轮次和耗时。这些数据用结构化日志输出方便后续分析。我用过最简单的方案是每次调用写一行 JSON 日志然后用脚本聚合。复杂一点可以接 OpenTelemetry但初期没必要先把日志打全。6.3 从单 Agent 到多 Agent 的扩展单 Agent 跑通后自然会想多 Agent 协作。但多 Agent 的复杂度不是线性增长是指数增长。通信、状态同步、冲突解决每一个都是坑。我的建议是先把单 Agent 的 harness 做扎实再考虑拆分。如果一定要拆先从“规划 Agent 执行 Agent”这种简单分工开始。规划 Agent 只负责拆任务执行 Agent 只负责干活两者通过 harness 里的任务队列通信。这样职责清晰出问题也好定位。7. 一些个人体会Rust 写 harness 的初期成本确实比 Python 高编译报错多、生命周期要理清楚。但一旦跑起来那种稳定感是值得的。我有个服务连续跑了三个月没重启内存曲线平的像一条直线。换成带 GC 的语言我可能每周都要看一眼内存。Codex 类 Agent 的竞争到最后不是比谁的模型大是比谁的 harness 更懂任务、更懂错误、更懂恢复。模型会越来越强但 harness 的工程积累是每天都要做的功课。这句话我越用越觉得对harness 总比模型快一步因为模型在等下一次训练而 harness 每天都在进化。最后分享一个小技巧给你的 harness 加一个“干跑模式”不真正执行工具只打印将要执行什么。调试复杂任务时这个模式能帮你快速看清 Agent 的决策路径比看日志高效得多。