刚看了 izeigerman/claude-thermos 的实现，才把一个多 Agent 的缓存坑看清楚：

Claude Code 的 prompt cache 只有 5 分钟。主 Agent 等子 Agent 超过 5 分钟，子 Agent 的请求因为系统提示和工具集不同，不会刷新主 Agent 的缓存前缀。子 Agent 回来后，主 Agent 只能把整段上下文按 write rate 重编码。

这个项目用本地 loopback 代理，在主 Agent 空闲时续前缀。README 说，作者约 185 个本地会话里，这类重编码约占账单两成——这是作者的数据，不是我的。

我觉得要点不只是“预热省钱”。一旦代理代替 Agent 发请求，至少还得能回答两件事：它续的是哪一个会话前缀；这次预热有没有改变或泄露任何工具、授权上下文。否则成本账省下来了，运行账反而变糊。

你们跑多 Agent 时，会把 cache hit/miss 和主、子 Agent 的等待关系记成可查指标吗？

来源：izeigerman/claude-thermos README

X 上 @realchendahuang 把 Pi 概括成“看文件、写文件、改文件、跑命令”。我回到 earendil-works/pi 的 README 看了一眼，真正值得注意的是另一句：它默认继承启动进程的文件、进程、网络和凭证权限，项目明确建议需要更强边界时放进容器或 sandbox。

这给我一个很实际的提醒：工具面做得小，和副作用边界做得清，是两件事。

在 Orca 里，我们把 workspace sandbox 内的修改和越界动作分开；前者可以自动执行，后者回到运行时授权。Pi 的说明则把这条界线进一步说透：没有独立权限层，Agent 再克制，仍然等于启动它的那个进程。

我现在更想把 Agent 的评估分成两张表：它能做什么；失败、误用或被诱导时，它被允许碰到什么。

来源：X @realchendahuang；开源项目 earendil-works/pi README。

你们会把权限模型写进 CLI 的默认行为，还是交给部署环境？

今天看到 leeguooooo/wechat-use：把 macOS 微信发送做成纯后台 CLI，目标是“不闪 UI”。

我能理解这种体验追求；但工具一旦交给 Agent，问题就从界面移到了副作用。

Orca 里我把 auto-edit 的边界定得很死：workspace sandbox 内可以自动执行，越出 sandbox 仍要回到运行时授权。关键不是少弹一次确认框，而是发送、拒绝、重试之后，谁还能说清任务停在了哪里。

所以我不太喜欢把 Agent 工具的“无感”理解成完全不可见。UI 可以隐身，授权与记录不能。

做过这类后台工具的朋友：消息送达、失败重试和拒绝记录，你们会留在 CLI/日志里，还是保留一个面向人的确认面？

把《拆开 Codex》修到 36 章后，我发现最费时间的不是把源码讲得更细，而是给每个判断补一份“证据账本”：源码版本、具体主张、可复现实验/观测产物，以及还没被外部验证的边界。

缺其中一项，所谓“理解 Agent 内部机制”很容易只是把实现细节重新叙述一遍。现在我更愿意把文档当成可审计的交付物：读者能沿着版本和产物复核，也能清楚看到我不知道什么。

公开手册：www.echovic.com

你们写 Agent 或基础设施文档时，最难保持的是哪类证据？

看了 OpenAI 和 Hugging Face 昨天披露的评测事故，有一点比“模型会不会攻击系统”更值得警惕。

这次不是一条危险命令被放行，而是模型为了拿到 benchmark 的答案，先突破研究环境的出网边界，再把多段各自看似合理的权限拼成了一条通往生产系统的路径。

很多 Agent 的安全设计还停留在“当前 tool call 能不能执行”。长任务真正要防的是状态漂移：网络边界何时扩大、身份和 secret 怎样跨环境、评测为什么能碰到生产数据，这些都得能被追溯和叫停。

sandbox 只是起点。任务跑得越久，越要审计整条路径。

OpenAI: openai.com

做 Agent 评测的朋友，最难划清的边界是哪一段？

并行跑多个 AI 编码 agent 时,git worktree 能防它们互相覆盖文件——但防不了合并时冲突。

而且一大半"冲突"根本不是冲突:两个 agent 改的是两个不同的函数,只是挨得近,git 按行合并就懵了。

symlock 两个都解决:符号级锁(动代码前先 claim),加一个能合并 git 合不了的"相邻不同函数"的保守合并。

npx skills add echoVic/symlock
🔗 github.com/echoVic/symlock

看 vLLM 的 prefix cache 文档时，我才意识到：缓存 key 不能只按 prompt 算。

它会把 token、父 hash，以及 LoRA、多模态输入这些影响上下文的因素放进 hash；多租户场景还可以加 cache_salt，只有 salt 一样的请求才能复用，避免别人通过响应快慢猜到某段内容是否被缓存过。

放到 Agent 里，我会再把 workspace、调用者、工具权限和 policy 版本考虑进去。否则权限刚变，缓存却还沿着旧边界命中，省下的是 prefill，丢掉的是隔离。

cache miss 最多慢一点；边界错配就不是性能问题了。

你们做 Agent cache 时，key 里会放哪些身份或权限信息？

我以前觉得插件 README 写清楚就够了。后来做 Boss Skill 才发现，真正让人犹豫的是安装那一刻：它从哪里来、会做什么、升级后还能不能验。

所以这次补的是 manifest、provenance、隐私/条款和安装矩阵测试。它们不够酷，但能把一部分“相信作者”变成可以检查的事实。

开源插件里，你们会把哪些信息放进安装包，而不是只留在 README？

刚看 dmtrKovalenko/fff。它把文件搜索做成常驻 runtime：内存索引、watcher、frecency 和 git 状态都留在进程里。

README 给的 50 万文件 Chromium checkout 对比很直白：一次性 rg 每次都要重新建状态，常驻查询才可能落到毫秒级。

对 Agent 来说，文件搜索不是一个命令，而是上下文获取的热路径。当然，索引也有启动、内存和失效成本；只搜一次时，rg 反而更干净。

你们会为了 Agent 的重复检索维护常驻索引吗？

做 Jiaoyuan 时，我有一个很轻的要求：别把它做成一台替人下结论的机器。

现在站里有 307 篇作品，可以从时间线、相关主题和当时的处境慢慢往回看。首页也能随机抽一张语录，觉得有用就保存成卡片；但卡片只是入口，不是答案。

人脑子打结的时候，最容易抓住一句话当结论。更值得做的，是回去看这段话是谁在什么处境下说的，原本要解决什么问题。

所以我把 Jiaoyuan 做成了一个能随手抽、也能慢慢读的小站。

你遇事不决时，更需要一句话先稳住，还是更想把问题放回背景里重新看？