关于我
我是一名工程师，过去几年在做后端与工具链，最近两年把大部分精力放在 Agent 系统上。写代码的时间远多于写文章的时间，所以这里的东西不多，但每一条都是自己动手验证过的。
我关心的问题很具体：怎么让模型稳定地调用工具、怎么在一条长链路里保住上下文、怎么把一个看起来很聪明的演示变成半夜不会炸的服务。这些问题没有漂亮的答案，只有一堆互相牵制的取舍，而我对取舍比结论更感兴趣。
这个站点是我自己写、自己维护的，没有团队，也没有排期。想写的时候写，写完就发。
我在做的事
Agent 工程不是一个单点技术，它是模型、工具、状态、评估和运维交叉出来的一块地带。目前我大部分时间花在下面三件事上。
工具层
把业务能力拆成模型能理解的原子操作，并给每个操作配上可读的失败信息——失败原因要能让模型自己判断下一步，而不是抛一句看不懂的堆栈。
状态层
把一次任务的中间产物持久化下来，让长流程可以中断、恢复、重放。调试一次线上问题，靠的往往不是日志，而是能原样再跑一遍。
评估层
用固定的用例集而不是感觉来判断一次改动是不是真的变好了。评估集要能长期维护，也要敢往里加难看的边界用例。
内容方向
写下来的东西大致分四类，长度不一，短的可能就是一段结论，长的会带上完整的复现过程。
工程笔记
踩过的坑与复现步骤，重点写清楚当时为什么选了这个方案，以及后来为什么又换掉。
架构拆解
把公开产品的 Agent 流程按数据流画一遍，看它在哪一层做了妥协，妥协的代价是什么。
工具实验
小工具、脚本和提示词结构，能直接拿去用的那种，附上失败案例和使用边界。
阅读记录
论文与开源项目的摘录，只记我认为会影响工程决策的那部分，不做通篇翻译。
近期记录
-
把任务编排从链式改成状态机，重试逻辑终于可以被解释清楚，而不是靠经验猜。
-
写了一版工具描述规范，统一了参数命名和错误码，模型选错工具的比例明显下降。
-
用回放日志定位了一个只在长会话里出现的上下文污染问题，根因是摘要策略把关键约束压掉了。
-
给内部评估集补了四十条边界用例，其中三分之一是过去真实失败过的输入。
联系方向
我不接咨询，也不做推广，但很乐意和认真做事的人聊具体问题。技术讨论、方案质疑、指出我写错的地方，都欢迎。
消息里如果能带上下面三件事，回复会快很多；方向对得上我会回，方向不对也会尽量说一句为什么。
- 你正在解决的问题是什么，以及它为什么值得解决。
- 你已经试过哪些做法，结果是怎样的。
- 你现在卡在哪一步，需要的是信息、判断，还是纯粹想找个人反驳一下。