今天一整天都在跟 AI agent 打交道，但做的是两件很不同的事：一边在 XX 项目里用 benchmark 驱动 todo 提取质量的提升，一边在 blagent 里让 AI 当产品经理分析需求然后自己实现。
两件事表面没关系，但做完之后发现有个共同的问题贯穿始终：AI 系统怎么学习用户的偏好，怎么记住该记的，怎么忘掉该忘的。
XX：benchmark 驱动的 LLM pipeline 迭代
XX 是一个会议 AI 助手，核心链路是：语音转录 → todo 提取 → 自动执行。今天的重点是 todo 提取这一环——从会议对话里找出可执行的任务。
之前的提取效果一直"感觉还行"，但到底行不行，没有数据说话。所以今天第一件事就是搭评估体系。
管理好自己的配置
不过还没开始写 benchmark，就先被基础设施绊了一下。测试脚本跑起来全部超时，LLM 调用一个都通不了。
问题不在代码——是服务配置没跟上环境变更。LLM 调用走的是内部 gateway，而 gateway 地址在最近一次迁移后变了，本地配置还是旧的。这种事情说起来很简单，但排查的时候只能看到一个"连接超时"的错误，不会告诉你"你的配置过期了"。
改了两行配置就好了。但这件事提醒我一个容易忽视的点：LLM 应用不只是 prompt 和模型，infra 层的配置管理同样重要。尤其是多环境部署的时候，一个配置漂移就能让整个 pipeline 静默失败，而且 debug 信息往往不够直观。
从"感觉还行"到数据说话
配置调整好之后，开始正式搭 benchmark。思路很直接：构造一组测试 case（模拟的会议转录），每个 case 标注期望提取出的 todo items，然后跑提取 pipeline，对比实际输出和期望输出，算准确率。
第一轮跑完，数据就暴露了问题。提取出的 todo 里有不少"伪 todo"——比如"讨论一下方案 A 和方案 B 的利弊"。这在会议里是讨论，不是任务。人能区分，但 LLM 的 prompt 没有给出清晰的判断标准。
中间有个有意思的时刻：第二轮迭代后分数提高了，但我突然意识到——测试集和训练集是同一批数据。Claude 可能是在"过拟合"这几个 case。于是临时拆出一个 validation set，果然表现没那么好，但至少知道了真实水平。
这个经验适用于所有 LLM prompt 调优：如果你的测试集和开发集是同一批，你看到的改进可能是幻觉。
执行侧：context 从哪来
todo 提取质量上来之后，另一个问题冒出来了：执行 agent 拿到 todo 后缺上下文。比如提取出"给张三发会议纪要"，但 agent 不知道张三的邮箱，也不知道会议纪要内容。
解决方案是加了一个 transcript context 注入层——把 todo 对应的会议片段直接塞给执行 agent。用 TDD 方式实现：先写测试定义 contract，Claude 照着 contract 写代码，大部分时候一次过。
Blagent：让工具学会认识它的用户
下午切到 blagent——就是生成这篇博客的工具。上午让 Claude 当产品经理分析了一圈需求，下午实现。但做着做着，方向从"加功能"变成了一个更根本的问题：这个工具怎么认识我？
从"生成博客"到"学你的风格"
早上的 dogfood 暴露了几个问题：生成的博文太短（700 字）、只写了一个项目忽略了其他的、AI 味太浓。这些不是能力问题——Claude 写得了长文，也能覆盖多个项目——而是没人告诉它该怎么做。
但一条条加规则治标不治本。真正的问题是：这个工具不认识我。它不知道我关心什么、擅长什么、写作偏好是什么。每次都是从零开始猜。
所以我们搭了一个两层的学习系统：
voice.yaml 记录"怎么写"——语气、用词习惯、避免的表达方式。这是从我和 Claude 的对话里提取的，比如我经常用反问句，不喜欢排比和感叹号堆砌。
profile.yaml 记录"写什么"——我的技术专长、兴趣方向、持有的观点、内容偏好。比如知道我关心 AI agent 架构和评估方法论，就不会给我写入门科普。
学习的三个通道
光有数据结构不够，关键是怎么更新。我们设计了三个输入通道：
第一个是草稿编辑的 diff。我在 Ghost 上改了博客草稿——把 Klik 匿名成了 XX，删掉了一段调试过程——工具拉回编辑后的版本，和本地原版做 diff，自动提取信号：删掉的段 → content_preferences.dislikes，匿名化的操作 → "不暴露内部项目名"。这个反馈是最真实的，因为用户是用行动投票。
第二个是对话中的学习。在和 Claude 聊天时随时可以说"我对分布式系统感兴趣"或"别再写调试细节了"，AI 直接更新 profile。
第三个是 CLI 直接添加。blagent profile add expertise "distributed systems" 这种，适合脚本化或者想快速加一条的场景。
比记住更重要的是遗忘
做到这一步的时候，突然想到一个问题：这个系统只会往里加东西，永远不删。时间长了会怎样？
半年前我可能偏好详细的调试过程，现在觉得琐碎了。两条矛盾的偏好共存在同一个文件里，工具不知道听哪个。什么都记住，等于什么都不突出——变成了一个"平均值用户"的画像。
这其实是所有记忆系统的核心问题，不只是 blagent。XX 的 memory 系统也面临同样的挑战：用户的习惯在变，联系方式在变，项目优先级在变。只记不忘的系统最终会被自己的历史数据淹没。
遗忘机制还没实现，但方向已经比较清楚：时间衰减（久没确认的记忆降权）、矛盾检测（新旧冲突时替换而非共存）、容量上限（满了淘汰最旧的）。这可能是下一步最值得做的事。
一天下来的认知
今天两个项目的工作，最后汇聚到同一个方向：AI 系统怎么真正理解它服务的人。
XX 的 benchmark 驱动迭代解决的是"AI 的输出对不对"——有标准答案可以对比。blagent 的学习系统解决的是"AI 的输出像不像你"——没有标准答案，只能从用户行为推断。
两个问题都指向一个更底层的认知：调优不是让 AI 变聪明，是让你的指令（和记忆）变清晰。无论是 prompt、benchmark、voice profile 还是 content preferences，本质上都是在把模糊的"我想要什么"变成具体的、可执行的信号。
而遗忘，可能是这个信号系统里最被低估的能力。
人机共创 · Blagent