2025 年，大家嘴里都在说「Agent」，但真正能在生产环境里、帮团队稳定做完活的 Agent，其实并不多。
PostHog 用了一整年，从一个只有「生成趋势图」单一工具的小玩具，迭代到了今天上线的 PostHog AI——一个真正在产品里「驻场」的智能分析师：
-
它能自己写 SQL、跑多步分析
-
会搭建 feature flag 和实验
-
还能主动去排查高影响错误
-
整个过程在一个循环里跑完，自己检查、自己修正
我们在这个过程中，踩了很多坑，也收获了不少确定性的经验。下面就是这一年里，我们关于 Agent 的 8 个核心学习，希望对你正在做或准备做 Agent 的团队，有点参考价值。
01 模型升级是推土机：你以为改一点，其实会变一片
这一年里，唯一不变的事情就是：模型在疯狂进化。
12 个月前，「推理模型（reasoning models）」还算是实验品；今天，如果没有强推理能力，Agent 基本做不了什么严肃活。
我们自己的两个重要分水岭是：
-
用上了 OpenAI o4-mini 做性价比推理
复杂查询、需要先探索再下结论的分析任务，明显变得更简单、更可靠。
-
换到 Anthropic Claude 4 系列后，工具调用可靠性大幅提升
Agent 终于可以放心开放一大堆工具，而不是「用一个挂一个」。
目前我们的核心 Agent 循环用的是 Claude Sonnet 4.5，在质量、速度和成本之间比较均衡——但我们也很清楚：这也会很快过时。
👉 真正的教训是：
不要低估模型升级的影响面。
你以为只是「精度提升一点点」，实际上是整套架构、策略、prompt 和工具设计都要跟着重想一遍。
02 工作流输给 Agent：图再漂亮，也不如一个能自我纠偏的循环
在 GPT-4o 早期，我们和很多团队一样，最开始是迷恋「图形化工作流」的：
-
画一张节点图：先 A 工具，再 B 工具，再 C 工具
-
想象成一个完美的业务流程「蓝图」
但事实是：图是给人看的，不是给 LLM 干活用的。
在图式工作流里，LLM 有几个致命问题：
-
很难自我纠错
-
一旦丢上下文，就很难补回来
-
实际用户问题永远偏离「理想流程」
后来，模型升级之后，我们把架构大幅简化成：
一个 单一循环（single loop） 的 Agent，不断在同一套对话上下文里：
看起来结构「土」了一点，但它能持续工作几十步，边走边修正，真实完成复杂任务——这才是关键。
很多人问图里那个奇怪的「switch mode tool」是什么？
简单说，它是我们的 「模式切换 / 工具搜索」能力，帮助 Agent 在 PostHog 庞大的产品面上，快速找到「现在最该用哪个工具」。这个细节之后会单独写一篇，我们就先卖个关子。
03 一个循环 > 一堆子 Agent：层层抽象，层层掉线
Agent 火了之后，大家很自然会想到「职能分工」：
CEO Agent → 派活给 Engineer Agent → Tester Agent 来验证 → PM Agent 提意见……
脑洞很大，现实却很骨感。
对 LLM 来说，最关键的资源是「上下文」：
-
每多一层「角色」和「抽象」，上下文就丢一层
-
工具调用之间的联系被切断，自我纠偏能力随之消失
-
最后看上去结构很优雅，实际表现却很「蠢」
这并不是说子 Agent 完全没用——当你需要并行执行一些「相对独立的任务」时，它们是有价值的。
但只要任务是强耦合、多步、需要频繁回头修正的，我们发现：
Claude Code 的成功，某种程度上就是这个路线的最佳证明。
04 To-do 工具是隐藏大招：让 Agent「记得自己要干嘛」
前面说了这么多「单循环」，其实里面还有一个小秘密武器：todo_write 工具。
它本身非常简单：
-
每一步操作结束，LLM 用这个工具写下接下来要做什么
-
工具本身其实什么都不干，只是把「下一步计划」显式化
效果却非常夸张：
-
Agent 不再「走着走着就忘了最初的目标」
-
出错后能自己回顾「我原本打算做什么」
-
多步任务可以跑得非常长，且方向感更强
写 To-do 对 Agent 来说，就像以前的 chain-of-thought 一样，是一种「自我约束 + 自我提醒」的超级能力。
05 上下文是生命线：你的 Agent 也需要一份「CLAUDE.md」
现实世界里的任务，几乎都长这样：
如果你不知道：
-
CFMP 是什么？
-
它在这家公司的产品矩阵里是什么位置？
-
用户大致路径长什么样？
这句话基本就是一堆拼错的字母。
我们发现，要让 Agent 执行真实任务，必须给它一个等价于 CLAUDE.md / PROJECT.md 的东西——一份持久、核心的上下文，永远挂在对话旁边：
-
公司是做什么的
-
主要产品线
-
关键事件 / 指标 / 命名
-
常见缩写和内部黑话
但问题也来了：
没人喜欢新工具上来就要求「写好几页配置文档」。
我们的做法是：
-
借鉴 Claude Code，做了一个 /init 命令
-
Agent 会通过多步 Web 搜索（目前用的是 GPT-5-mini）自动去理解你的产品和业务
-
如果你的数据里缺少公开 URL，再少量地问你几个关键问题
-
最终生成一个项目级别的「记忆」，供后续所有任务使用
更长远来看，我们认为：
上下文不只在 Web 上，也在你的 Slack、邮箱、文档和代码里。
这是一个已经有很多解决方案、但还远没被真正「解决干净」的问题，我们也在继续探索。
06 把每一步都摊开：黑盒再“准”，用户也会不放心
一开始，我们也尝试过「把细节藏起来」：
-
不展示推理过程
-
不展示失败的工具调用
-
不展示调用参数，只给最终结果
用户反馈非常一致：
「看结果还不错，但就是有点不踏实，不知道它到底干了什么。」
后来我们反其道而行之：
-
流式展示每一次工具调用、参数、返回结果
-
连推理 token 也实时展示
结果很有意思
只要用户能看到 Agent 在「纠错、反思、重试」，即便有时候多绕两步路，信任感也明显增加了。
可以说，人和 LLM 在这点上很像：
一个完全不透明的黑盒，会让人下意识地不信任。
而暴露细节，反而能让大家更愿意长期依赖它。
07 框架有时是阻力：在战场上，越底层越安全
我们从一开始的 OpenAI Python SDK，迁到了 LangChain + LangGraph。
如果是今天再做选择，我们大概率就不会这么做了。
原因有几个：
-
你会被框架的「世界观」锁死。
LangGraph 的抽象非常优雅，但当模型能力、产品需求快速变化时，你会发现很多「原本看起来合理的边界」变成了束缚，重构成本极高。
-
LLM 进化速度远大于框架更新速度。
新模型、新能力（比如不同家的 Web search、tool calling 格式）一出来，抽象层很容易「崩」：
-
想统一 OpenAI 和 Anthropic 的搜索结果格式？对框架来说是噩梦。
-
你只想用某家模型的新特性，却发现框架还没跟上。
-
生态太碎片，沉没成本太高。
今天选了 A 框架，明天 B 出了个 killer feature，你要不要换？
每一次切换，都是一笔不小的工程债。
当然，轻量封装还是有价值的，但我们的结论是：
在 Agent 这种快速演化的赛道上，
尽量保持中立、低耦合，
当成「就是在调用一个函数」来设计系统，会更安全。
08 Evals 重要，但远不够：真相藏在用户的真实使用里
很多人会说：「只要 eval 做得好，Agent 质量自然就上去了。」
我们同意 eval 很重要，尤其是对基础模型来说。
但在 Agent 场景 下，情况要复杂得多：
-
想要构造一个「足够真实」的多步任务环境，本身就是一个巨大工程
-
你必须支持「所有 Agent 可能调用的工具」，才能真正评估表现
-
大部分 eval 只能覆盖「你想到的 happy path」，而真实用户总会走你没想到的路
我们最后发现，比起「一上来就设计一堆 eval」，更有效的路径是：
-
先把 Agent 真正放进生产环境
-
设立固定的「Traces Hour」
-
我们团队每周会拿出一段时间，只做一件事：
逐条看真实用户的 LLM 调用轨迹（trace）
-
找出哪些地方 Agent 工作得好，哪些地方明显「走歪」了
-
再基于这些真实问题，反过来设计 eval
这套方法带来的好处是：
工程投入都精准砸在「真用户真的在痛」的地方，
而不是停留在我们自己想象的 demo 上。
我们现在用 PostHog AI 在做什么？
在 PostHog 内部，我们已经用 PostHog AI 好几个月了。
它不是完美的，但已经能稳稳接住很多原本要人肉做的事情：
-
调试复杂 SQL
-
看用户行为路径，找 drop-off、关键行为
-
搭建实验、评估结果
-
沿着 session 和 error 追查问题来源
真实世界的产品数据，其实就是一碗打结的面条：
-
事件串成会话
-
会话分支到错误
-
点击穿过多条路径……
PostHog AI 的价值，就是帮我们把这碗面条顺成一条可理解的「故事线」。
如果你已经在用 PostHog，可以这么试：
-
打开 PostHog
-
右上角点「PostHog AI」
-
授权它访问数据（需要管理员权限）
-
运行 /init，让它先了解你的业务
-
然后，开始直接「派活」给它
