长程 Agent Harness 的 5 个设计模式与避坑指南

长程 Agent Harness 的 5 个设计模式

一次性 Agent Harness 崩了会当着你的面停下来；长时程 Agent Harness 崩了会悄悄隐藏问题、继续运行。

这五个真实事故就经常发生： 1. prompt 缓存从未命中但账单看起来正常 2. 每轮回复前抽取记忆拖慢响应，收益却要下周才体现 3. 一次部署抹掉 Agent 花了一整个会话安装的工具，它默默重装并一路汇报进度 4. 子 Agent 超时，父 Agent 却愉快地报告任务完成 5. 一条命令绕过安全守卫访问云元数据服务，且零日志

来自 @GoogleCloudTech 分享，作者 @Saboo_Shubham_ @secchi_elia @lavinigam 为这些问题整理了五种设计模式。

1. 稳定前缀 prompt 缓存命中率为 0，原因是每轮把变化的记忆注入 system prompt 顶部。按变化速度分层——顶部冻结（指令、工具定义）、中部慢变（用户画像）、尾部易变（记忆、计数器）。

仅此一改，95% 的 prompt 走缓存。检验方法：第二轮 cached token 仍为 0，就说明前缀在动。

2. 后台学习 记忆抽取从"回复前内联"改为"回复后异步"（write-behind）。

三道保障：持有强任务引用防 asyncio GC 掉写入中的任务；用最小权限的隔离子 Agent 执行，防递归；两次抽取间隔 120 秒防抖。关机排空超时必须低于宿主清理上限。

3. 持久化工作区 一次常规部署抹掉了 Agent 装好的工具，它默默重装并继续汇报进度。工作区应按用户而非会话划分，跨轮次存活，通过统一执行接口访问（本地文件系统与生产沙箱无感切换）。

教训：已删除和正在启动的环境都返回 502，别用共享状态码判存活。

4. 显式失败 子 Agent 超时，父 Agent 报告"20 个测试全过"。根因是超时、步数耗尽、待审批、完成四种结局返回同一种字符串——半截过程读起来和完成报告一样。

解法：给每个终止状态命名，且重写摘要本身（"INCOMPLETE：未完成，勿报告为已完成"），因为模型读的是摘要不是字段。对无限循环设硬上限（每轮 200 次工具调用、每会话 50 轮），到限后剥离工具让模型写纯文本交接。

5. 守卫链 字符串匹配封禁 169.254.169.254，被 curl http://2852039166/ 绕过（同一 IP 的整数写法）。

原则：先规范化再比较。守卫按成本短路求值：外泄守卫（硬封禁，不可放松）→ 策略守卫（allow/ask/deny）→ 人工确认（最后才问，注意力最贵）。

全链无模型参与，微秒级、可审计，是仓库中测试最多的子系统。凭证按"守卫终将被攻破"设计：密钥注入环境而非 prompt，沙箱平台层禁出网，模型只见占位符。