回头看我们的Agent底座——六层构建栈：提示词、上下文、工具、安全、韧性、可观测
AI 小组成立快两个月了，我们的 Agent 底座终于有了个样子：一个内核，上面能挂不同的业务。趁着第一款产品上线前的空档，我把这段时间零零碎碎的设计按层整理了一遍，顺便检查一下有没有漏掉的地方。
清早眉間白雲生
朝霞化精靈 / 輕快 明亮 恆溫的伴侶 / 她與你共存 / 違背 對抗 相同的命運
愛與疼痛 / 不覺茫茫道路長 / 生活歷險 / 並肩莽莽原野荒
为一切设定预算——长对话里的上下文管理：token估算、上下文卫生与熔断
这个月公司成立了 AI 小组，开始正式做我们自己的 Agent 底座，第一个要支撑的是陪伴类的产品。它和 coding agent 很不一样：一次会话能聊上百轮，同一个用户会持续聊好几个月。原型阶段没暴露的上下文问题，一下子全冒了出来。
让Agent记住用户——跨会话记忆的设计：什么值得记、什么时候记、记多了怎么整合
最近公司在预研陪伴类的 AI 产品，长期记忆是绕不开的一块。用 Mem0 搭了个雏形，很快就遇到三个问题：琐碎的小事记了一大堆；用户上个月说喜欢、这个月说讨厌，两条记忆打架；「明天要考试」被原样存了进去，过了那天就成了一句没人看得懂的话。于是回头去看 Claude Code 是怎么设计记忆的。
子Agent、Fork还是协调者——多Agent模式怎么选，关键看还要不要中间输出
原型做到现在，主 Agent 身上的活越堆越多：查知识库、总结会话、提取用户信息、回复用户，全在一个上下文里。结果上下文涨得飞快，后台那些总结类的活还拖慢了主对话的响应。是时候把活拆出去了，但拆成几个 agent、怎么拆，又是一个新问题。
Agent的安全纵深——权限管线、提示注入防御与沙箱：为什么不确定就要阻止
最近在部门里推广 Claude Code，同事问得最多的一句是：它会不会把我的东西删了？与此同时，我们的 Agent 原型也开始接公司内部的接口和知识库文档，我自己也在担心另一件事：文档里要是夹了一句「忽略之前的指令」，它会不会照做？两个问题其实是同一个问题，于是系统地看了一遍 Claude Code 的安全设计。
改一次提示词就要多付一笔钱——Prompt Cache的原理，以及Agent怎么设计才不打破缓存
Agent 原型跑了一段时间，我顺手看了一眼调用记录里的缓存命中，低得离谱。排查下来发现，是我在系统提示词最前面放了当前时间和用户昵称，每一次请求的开头都不一样，缓存一次都没命中过。于是又回头去看 Claude Code 是怎么对待缓存的，发现它几乎是把缓存当成一等公民在设计。
用提示词控制Agent行为——六种引导模式，以及哪些约束该写进提示词、哪些该写进代码
公司开始做 Agent 了，我先搭了个对话类的原型。循环和工具都是现成的思路，真正折腾人的是系统提示词：写了「回答简洁一些」，模型照样长篇大论；加了一句全大写的「绝对不要」，它又谨慎过了头，连正常的事都不敢做。于是又回头翻 Claude Code 的提示词，看它是怎么写规则的。
工具描述就是给模型的API契约——Agent工具设计的原则：fail-closed默认值、结果预算与工具提示词
上次研究完 Agent Loop，手痒照着思路写了个小 agent 练手。循环很快就跑起来了，结果问题全出在工具上：描述写得随意，模型就乱传参数；工具报错被我吞掉返回了空，模型就一本正经地编了个结果。于是回头去看 Claude Code 是怎么设计工具的。
Coding Agent的心脏——Agent Loop：为什么要做成显式状态机，错误为什么要从轻到重地恢复
去年年底开始关注 coding agent，今年 2 月 Claude Code 出来以后几乎天天在用。用久了发现它很耐操：上下文满了会自己压缩接着干，输出被截断会自己续上，模型过载了还能换个模型重试。好奇这些行为是怎么来的，研究下来发现，答案都在 Agent Loop 这个循环里。
本站全新启航，采用Rust+NextJS全面重构
之前有推文也讲过，本博客一直部署在一台512M内存的小鸡上，之前的博客是springboot+Thymeleaf开发的，一个博客就占用了我300M的内存，现在rust后端+vercel托管的nextjs前端，一切都好起来了~