大家好，我是玄姐。
▼ 《双12 AI 原生应用落地专场》直播
预约保你有收获
今天，我们正式推出 PostHog AI，一款深度集成于 PostHog 平台的 AI 智能体。历经一年打磨，它已从黑客马拉松期间诞生的首个聊天原型，实现了跨越式发展。最初，它仅支持 “生成趋势图表” 这一项工具，毫无真正的智能体能力；而如今，PostHog AI 可通过数十种工具访问你的数据与配置，像不知疲倦的产品分析师般循环工作，直至完成你交付的任务：无论是多步骤产品使用分析、SQL 查询编写、新功能标志与实验配置，还是深挖高影响度错误等，所有操作均在 PostHog 生态内完成。经过全面的 Beta 测试，它目前每周已有数千名用户在使用。
这段旅程充满挑战。智能体的开发堪称矛盾：有人说设计智能体难度极高，确实如此；也有人说搭建一个智能体易如反掌，奇怪的是，这同样不假。
以下是我们在构建高效智能体过程中总结的核心经验。
1. 警惕模型迭代的 “推土机效应”
一年开发历程中唯一不变的是：模型迭代带来的影响远比最初预想的更为深远。令人惊叹的是，12 个月前推理模型还处于实验阶段，而如今推理能力已成为 PostHog AI 的核心竞争力。工具使用能力也实现了质的飞跃，2025 年 11 月的前沿模型已能更可靠地理解复杂工具。目前，我们采用 Claude Sonnet 4.5 作为核心智能体循环的底层模型，它在性能、速度与成本之间达到了完美平衡，但毫无疑问，这款模型很快也会被更新的版本替代。
在我们的实践中，两次与模型相关的关键突破为：
OpenAI o4-mini 带来的高性价比推理能力，这显著改进并简化了复杂查询的生成，尤其是那些需要数据探索才能完成的查询（再见了，ReAct 框架！）；
Anthropic Claude 4 系列模型实现的可靠工具调用，智能体终于能自主使用更多样化的工具，且不会偏离任务轨道。
预测模型升级的实际影响依然困难！Sean Goedecke 曾就此发表过一篇出色的文章。尽管当前模型的进步不像 GPT-2 到 GPT-3 那样惊天动地，但这种迭代从未停歇。
2. 智能体完胜固定工作流
图形化工作流曾被认为是完成任务的理想选择。在 GPT-4o 时代，通过相同的系统提示词循环调用工具极易造成混乱，因此我们花费数月时间探索新的图形化工具编排方式。看看我们迭代过的架构就知道了，那时我们的助手还叫 “刺猬 Max”。最初的版本甚至无法用文本回答问题，无论用户输入是什么，它都只会生成查询！
架构迭代历程
v0 版本
用户消息 → 路由器 → 摘要器
↓
趋势规划器→趋势生成器
漏斗规划器→漏斗生成器
核心问题：智能体除了生成洞见外什么都做不了，即便用户只是想闲聊。
v1 版本
用户消息 → 根执行器 → 查询
↓
趋势规划器→趋势生成器
漏斗规划器→漏斗生成器
留存规划器→留存生成器
SQL规划器→SQL生成器
↓
文档搜索 → 回复
核心问题：智能体在规划查询时已锁定洞见类型，无法判断是否需要 SQL 支持。
v2 版本
用户消息 → 根规划器（推理）→ 查询执行 → 查询
↓
过滤子智能体→趋势生成器
漏斗生成器
留存生成器
SQL生成器
↓
数据探索工具 → 文档搜索 → 回复
↓
过滤子智能体→趋势生成器
漏斗生成器
留存生成器
SQL生成器
↓
数据探索工具 → 文档搜索 → 回复
核心问题：查询规划与生成步骤无法获取上一步的完整上下文，过滤子智能体也存在同样问题。
最终架构
事实证明，图形化架构极不适合编排自由格式的工作。在图形结构中，大语言模型无法自我修正，上下文也极易丢失。如今，得益于模型能力的提升，PostHog AI 的架构变得简洁高效：
用户消息 → 根推理模块 → 模式切换工具
↓
分析工具模式/功能标志工具模式/回放工具模式等
通过循环反馈，大语言模型能够执行数十个步骤，同时持续验证输出结果。硬编码的工作流或许执行成本低，但当它无法真正完成任务时，一切都毫无意义。
图表中的 “模式切换工具” 是什么？这是我们的 “非秘密武器”。模式切换本质上是工具搜索的一种变体，对于将智能体支持的工具规模扩展到 PostHog 的全功能范围至关重要。后续我们将单独发文详细介绍。
3. 单一循环优于子智能体
即便在智能体循环中，人们也容易倾向于将任务执行拆分为专门的子智能体。设计这样的架构难道不巧妙吗？“组件 CEO 将任务委派给组件工程师，再由组件测试员验证结果，同时参考组件产品经理的意见”。
想法虽好，但结果却不尽如人意。上下文对大语言模型至关重要，每一层抽象都会导致上下文丢失，智能体串联工具和自我修正的能力也会随之消失。子智能体并非毫无用武之地，当需要并行处理工作时，它仍是最佳选择。关键在于，被委派的任务必须是独立完整的，最好能互不干扰。
从 Claude Code 的成功中我们可以看到，单一的大语言模型循环配合简单工具，就能创造出惊人的效果。感谢这种 “涌现能力”。
4. 任务清单（To-dos）是核心竞争力
没错，单一的大语言模型循环加统一的消息历史记录，效果确实神奇。
但还有一个关键秘诀：todo_write工具。它看似简单通用，却是让大语言模型保持专注的天然方式。每次大语言模型在步骤结束时使用该工具，都会强化下一步的行动目标，而这个工具本身无需执行任何实际操作。
突然间，智能体不再会在几次工具调用后迷失方向，而是能持续推进任务，不断修正路线。撰写任务清单就像曾经的思维链（Chain-of-Thought）一样，是一种直观的核心竞争力。
示例：关联 2023 年 1 月以来的 AWS 故障与页面浏览量下降情况
思考过程：我将帮你关联数据中 AWS 故障与页面浏览量下降的关系。以下是分步计划：
任务清单（0/4）：
搜索 2023 年 1 月以来的 AWS 故障记录（进行中）
从项目分类法中获取页面浏览事件数据
分析 2023 年 1 月以来的页面浏览量趋势
将 AWS 故障日期与页面浏览量下降情况进行关联
5. 更广泛的上下文是关键
我之前提到过上下文的重要性吗？它在任务的每一步都不可或缺，因为人们对任务的描述往往模糊不清。比如，你会如何回答 “用户在 cfmp 转化过程中的流失点在哪里？” 这个问题？看起来像是有一堆拼写错误，除非你知道 CFMP 是用户提供的一款产品，并且了解它在用户业务中的定位（这是一个真实案例）。你的智能体需要一个类似CLAUDE.md的文件，一份始终附带的核心上下文。
核心上下文能极大改善智能体的执行轨迹，但这也给用户增加了新的操作负担，没人喜欢新工具带来额外的设置工作。我们发现，核心上下文的创建必须轻松自然，而非强制要求。最终，就像所有伟大的创作者都会借鉴他人经验一样，我们从最优秀的实践中汲取灵感 ，借鉴 Claude Code 的设计，实现了/init命令。
在 PostHog AI 中，/init命令通过多步骤网页搜索（目前使用 GPT-5-mini）了解你的产品和业务，搜索结果将构成智能体的项目级记忆。如果你的数据中没有可用于搜索的 URL，系统会直接询问几个问题，但我们会尽量减少这种情况。
示例：/init 命令执行流程
/init
我将查找关于你的产品的信息，以更好地理解你的项目。从你的事件数据来看，us.posthog.com可能相关。这可能需要一分钟...
以下是我在us.posthog.com上找到的信息：
PostHog（面向美国地区客户的产品部署于us.posthog.com）是一款开源核心型产品分析与产品工程平台，将基于事件的分析、会话回放、实验/功能交付和数据基础设施工具整合于一体。它提供PostHog Cloud（多区域、按使用量付费的SaaS服务）和自托管开源软件（MIT许可）两种形式，专为希望拥有自有数据并在产品信号附近进行分析的产品工程师和产品团队设计。
产品功能：
- 核心产品套件（多产品集成于同一平台）
- 产品分析/洞见生成
- 趋势、图表、用户分群、漏斗、留存、粘性、生命周期、关联分析和高级路径分析
- 可视化无代码洞见，同时为高级用户提供编程式查询
- 仪表板与报告（随使用量增长而扩展）
- 从分析扩展为集成式产品与数据工具包（功能标志、实验、回放、数据仓库、数据管道、AI功能），目前提供Cloud版、自托管版及企业套餐。
以上是否准确描述了你的项目？
[是，保存此信息] [否，不完全准确]
上下文无处不在。它存在于网页中，也存在于你的 Slack 聊天记录、电子邮件收件箱和笔记应用里。这是应用 AI 领域中一个已有多种解决方案但尚未完全解决的问题。我们已有一些想法，敬请期待。
6. 展示每一步执行过程
我们曾尝试隐藏一些看似粗糙的细节：完整的推理链、失败的工具调用、工具调用参数等，不让用户看到。但我们收到的反馈始终如一：“我能看到输出结果，但过程是个谜，让人难以信任。”
此后，PostHog AI 开始实时流式展示每一次工具调用和推理过程。事实证明，人类和大语言模型很相似，或者说大语言模型和人类很相似。无论结果多么出色，黑箱操作都无法让人信服。细节能让我们对正在发生的事情充满信心。所以，把所有一切都展示出来吧，好的、坏的、不完美的。
示例：统计过去 90 天内 $ai_trace 事件输出中包含 “你完全正确” 的比例（需生成图表）
思考过程 >
我将帮你生成一张图表，展示过去90天内$ai_trace事件输出中包含“你完全正确”与不包含该短语的数量对比。
首先，我需要验证你项目中的事件和属性详情。
[读取分类法]
思考过程 >
我在列表中未看到“output”属性。让我搜索属性值，看看是否有捕获输出内容的属性。
[读取分类法]
思考过程 >
让我查看$ai_generation事件，该事件被描述为包含输出信息。
[读取分类法]
思考过程 >
让我搜索文档，了解如何从AI追踪事件中获取输出内容。
[执行搜索 √]
思考过程 >
根据文档，$ai_trace事件包含$ai_output_state属性，该属性存储输出内容。让我验证该属性是否存在于你的数据中，然后生成图表。
7. 框架可能成为 “绊脚石”
早期，我们从 OpenAI Python SDK 迁移到了 LangChain + LangGraph。但如今，我们绝对不会再做这样的选择。
每次使用一个框架，你就会被锁定在它的生态系统中。还记得 “JavaScript 每秒都有新的前端框架诞生” 的梗吗？现在的大语言模型领域也是如此，只不过大语言模型的进化速度远比 JavaScript 快，而这些框架提供的价值却相对有限。它们的生态系统极其脆弱。
像 LiteLLM 或 Vercel AI 这样的大语言模型调用抽象层，在 AI 提供商推出新模型或新功能时很容易崩溃。例如：网页搜索结果的格式问题，OpenAI 和 Anthropic 的返回格式完全不同，而框架却试图维持统一的接口。
更糟糕的是 LangGraph 这类大语言模型调用编排工具。虽然概念上很优雅，但它们会将你束缚在特定的思维模式中。当这种模式过时后，祝你好运，把所有东西重构一遍。
或许有一天 AI 领域会出现像 React 那样的主流框架，但目前 “框架大战” 仍在激烈进行。保持中立和底层调用可能是最佳选择。毕竟，本质上只是调用函数而已。
8. 评估（Evals）远非万能
有人说评估（Evals）可以解决所有问题。对于基础模型而言：确实，这些数据集是基础性的。但对于智能体而言：评估是一个很好的工具，但实际情况要复杂得多。
现实世界错综复杂：对于许多真实场景中的多步骤任务，搭建一个足够复杂的测试环境，其难度甚至超过构建智能体本身。如果想要判断智能体的实际性能，这个环境必须支持智能体可能进行的每一种工具调用。毕竟，现实世界的细节远比想象中丰富。你可以通过评估轻松覆盖预期的 “顺畅路径”，但很快用户就会走出许多你从未设想过的路径。
我们发现，比原始评估更重要的是：关注真实使用场景，并临时评估智能体的工作表现。为此，我们推出了 “追踪分析小时（Traces Hour）”，PostHog AI 团队每周都会召开一次会议，100% 专注于分析生产环境中的大语言模型追踪数据（即真实用户交互数据）。只有基于这些实际调查得出的评估，才具有真正的意义。当你深入了解用户体验后，工程效率会提升 10 倍，构建智能体也是如此。
现状与进展
我们已经使用 PostHog AI 数月了。它并非完美，但能应对产品数据的复杂现实：所有数据相互关联，事件构成会话，会话衍生错误，点击行为跨越多条路径，就像一碗缠绕的面条。
PostHog AI 能解开这些复杂结构，重构出清晰、符合逻辑的序列。我们用它来调试 SQL、理解用户行为、设置实验和分析错误，这些工作原本需要在多个界面中切换或编写复杂查询才能完成。
现在就来试试吧：打开 PostHog，点击右上角的 “PostHog AI”，授予 AI 访问数据的权限（需要管理员权限），运行/init命令，然后开始向它下达任务。
未来规划
这仅仅是个开始。即将推出的功能包括：深度研究能力、复杂会话分析、后台分析生成的主动洞见，以及与代码的更紧密集成。在未来几周和几个月内，我们还将分享更多经验教训。
参考原文：
https://posthog.com/blog/8-learnings-from-1-year-of-agents-posthog-ai
好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~
PS：
▼ 《双12 AI 原生应用落地专场》直播
预约保你有收获
—1—
加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即预约！
)
)
