Google Cloud 团队总结长程 Agent Harness 的五个设计模式

长程 Agent Harness 的 5 个设计模式 一次性 Agent Harness 崩了会当着你的面停下来；长时程 Agent Harness 崩了会悄悄隐藏问题、继续运行。 这五个真实事故就经常发生： 1. prompt 缓存从未命中但账单看起来正常 2. 每轮回复前抽取记忆拖慢响应，收益却要下周才体现 3. 一次部署抹掉 Agent 花了一整个会话安装的工具，它默默重装并一路汇报进度 4. 子 Agent 超时，父 Agent 却愉快地报告任务完成 5. 一条命令绕过安全守卫访问云元数据服务，且零日志 来自 [@GoogleCloudTech](https://x.com/GoogleCloudTech) 分享，作者 [@Saboo\_Shubham\_](https://x.com/Saboo_Shubham_)[@secchi\_elia](https://x.com/secchi_elia)[@lavinigam](https://x.com/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 绕过（同一 IP 的整数写法）。 原则：先规范化再比较。守卫按成本短路求值：外泄守卫（硬封禁，不可放松）→ 策略守卫（allow/ask/deny）→ 人工确认（最后才问，注意力最贵）。 全链无模型参与，微秒级、可审计，是仓库中测试最多的子系统。凭证按"守卫终将被攻破"设计：密钥注入环境而非 prompt，沙箱平台层禁出网，模型只见占位符。   Google Cloud Tech@GoogleCloudTech [x.com/i/article/2090…](https://x.com/i/article/2090246025403408384) [🔗 View Quoted Tweet](https://x.com/GoogleCloudTech/status/2090248297214525569)