Agent harness 要隔离、可复现、可收尾

更新于 2026-06-12

**Agent harness 是给 Agent 搭的「调试房间」，本质回答三件事：隔离谁、怎么复现、怎么收尾。**

在真实产品链路里调 Agent，每次试错都可能污染数据、改坏真实内容、占用共享缓存、和别人的调试互相干扰。所以 harness 不是替代真实产品，而是让你能反复问：收到的上下文对不对、工具调用格式对不对、流式有没有卡住、失败信息是否清楚、会不会误写真实数据。

问题	内容
隔离谁	数据（假 fixture）、缓存（独立 Redis / key 前缀）、端口（独立服务）、模型调用（假模型或录播响应）、日志
怎么复现	固定测试数据 + 固定输入 + 固定模型响应，让失败可重跑
怎么收尾	每次生成 run id 便于看日志，调试结束清掉测试数据与缓存

默认不写真实数据，是 harness 的第一原则。

多项目共用同一个 CLI 时，不要改全局配置来满足单个项目。全局 provider/base_url 一改，所有项目、所有新开线程都会跟着变。更保守的做法是给该项目单独的 profile 配置文件 + 项目专用 env + 一个启动脚本，全局命令仍走默认。

前提认知：这类 CLI 通常没有「按项目自动切 provider」的稳定字段（只有项目 trust 之类的配置），provider 是全局或 profile 层的。所以「进入目录就自动用这套 key」要么靠改全局（风险最大），要么靠 direnv / alias / wrapper 注入。

第一版 harness 用起来「麻烦」通常不是方向错，而是停在底层工程接口：

缺的是面向日常的薄包装（2–3 个入口命令 + 一页「改 prompt → 跑 → 可选上传 → 再推 label」的文档），而不是把底层设计推倒。