构建 Agent Native Product：保险快查离线与在线实践演讲稿
这是一版面向技术同学的 30 分钟演讲逐字稿。正文以可直接朗读为主；每个需要展开的概念后，用“展开阅读”引用当前知识库中的相关文章。
开场
大家好，今天我想分享的主题是：如何构建一个 Agent Native Product。
这不是一个“怎么在产品里接一个聊天框”的分享，也不是单纯讲某个 Agent 框架怎么用。我想讲的是一个更高层的方法论：当我们真的要把 Agent 做进一个线上产品里，系统应该怎么分层，能力应该怎么沉淀，多个 Agent 应该怎么协作，以及在线体验为什么很大程度上依赖离线认知资本。
我的核心观点是：
构建 Agent Native Product，不是让一个模型在线上想得更久，而是用 OneAgent 构造可复用的领域智能体，用协议化协作模式约束多个 Agent 的交接、状态、证据和校验，把离线认知资本沉淀出来，再让在线系统低时延、可追溯、可校验地消费这些资本。
今天我会用保险快查这个真实线上产品来展开。
保险快查这个场景非常适合讨论 Agent Native。因为保险咨询不是普通问答。它有长条款，有健康告知，有核保规则，有理赔信息，有增值服务，还有很多监管和合规表达要求。用户问的也不是标准问题，而是“我这种情况怎么买”“这款能不能赔”“端午去尼泊尔爬山买什么保险”“我有高血压还能不能投”。
这些问题背后有非常复杂的上下文。如果所有事情都等用户来了以后在线从零推理，时延扛不住，质量也不可控。所以在保险快查里，我们逐渐形成了一个判断：在线 Agent 的聪明，很多时候不是因为它在线上想得更久，而是因为离线已经把该查的、该读的、该校验的东西沉淀好了。
这就是我今天要重点讲的“离线认知资本”。
展开阅读
什么是 Agent Native
先说什么是 Agent Native。
我认为，Agent Native 不是产品里有一个 Agent，而是产品形成了智能闭环。在 Product Plane 上，这个闭环大概是：用户提出意图，Agent 理解上下文，调度知识、工具和流程，交付答案、内容或行动结果，然后把反馈、失败样本和校验结果沉淀回系统里，让下一次满足用户意图的能力变强。
所以它和普通 AI feature 的区别在于：普通 AI feature 往往是一次性调用模型，生成一个结果。而 Agent Native Product 关注的是，这个系统能不能持续积累认知，持续校验结果，持续把错误变成下一轮能力。
这里有两个基础抽象。
第一个是 OneAgent。
OneAgent 解决的是“如何构造一个足够强的基础智能体”。它不是某一个具体业务 Agent，而是一个可以派生领域智能体的基础内核。
在我这里，OneAgent 至少包含几个部分：ReAct Loop、工具调用、state/VFS、SubAgent、middleware、checkpoint 和事件流。
Loop 让模型可以围绕目标持续行动；工具让它能连接外部世界；state/VFS 让中间产物和长上下文不必全部塞进模型窗口；SubAgent 让复杂任务可以隔离到独立上下文；middleware 把运行时纪律固化下来；checkpoint 让过程可恢复、可审计；事件流则让内部执行过程可以被产品侧消费。
有了这个基础内核之后，我们可以派生很多领域 Agent。比如离线链路里的 Host Agent、Supplementary Agent、World Knowledge Agent、Verify Agent，以及在线链路里的主 Agent、搜品子图、取证 Agent 等等。
但只有 OneAgent 还不够。多个 Agent 放在一起，不天然等于可靠系统。它们不能只是互相聊天，而是要遵守一组协议化的协作模式。
这里我不把它讲成某个行业标准协议，而是讲成工程上必须明确的几类契约。
第一类是任务契约。一个 Agent 接到的不是一句随意的自然语言，而应该是结构化任务：目标是什么，输入是什么，约束是什么，预期产物是什么，停止条件是什么。
第二类是交接契约，也就是 handoff。handoff 不是把完整上下文复制给另一个 Agent，而是交接一个可继续工作的状态。更具体地说，是任务描述加上 state/VFS 引用，再加上预期输出。这样可以避免上下文污染，也避免每个 Agent 都重新背一遍全量材料。
第三类是状态契约。事实不应该只存在于模型上下文窗口里。报告、素材、证据、审计日志、索引、校验结果，都应该进入 state。在我们的实现里，VFS 对应到代码中就是 state。模型上下文负责推理，state 负责承载事实。
第四类是证据契约。每个结论要知道来自哪里。保险场景尤其如此：一个结论到底来自投保页、保险条款、健康告知、核保信息、理赔材料、增值服务，还是外部世界知识，必须可追溯。
第五类是校验契约。产物必须可打分、可拒绝、可回调。合格才进入产品，不合格就返回错误信息或修正建议。没有 verify，Agent 生成的东西就很难进入 C 端产品主链路。
第六类是事件契约。内部执行事件不等于用户可见事件。多 Agent 系统内部是并发、嵌套、乱序的，但用户需要看到的是符合业务理解的过程，比如搜索、取证、生成答案。所以中间需要一层事件协议，把运行树翻译成产品流。
展开阅读
上下文供给链路
接下来进入保险快查的实践。
我先讲离线认知资本生产线，也可以叫“上下文供给链路”，英文可以叫 Context Supply Pipeline。
这条链路的目标，不是直接生成一个用户可见页面，而是把保险产品背后的分散信息，变成可追溯、可检索、可校验的上下文供给。它生产出来的不是一段文本，而是一组资产：context bundle、evidence、source map、vector index、校验分数、错误码和回调状态。
这里首先是 Host Agent。
Host Agent 会先查询投保页，下载产品素材，然后做 todo 规划。为什么要有 todo？因为保险产品材料非常长，如果一上来全部塞进上下文，模型很容易被淹没。todo 的价值是把长程任务拆成阶段目标，让 Agent 知道当前在查什么，下一步要补什么，什么时候可以结束。
接下来它会基于素材建立向量索引，再按需检索。也就是说，它不是把所有条款都读一遍，而是围绕当前产品分析目标，定位关键片段，逐步形成产品上下文包。
然后是 Supplementary Agent。
Supplementary Agent 负责补充主链路不一定天然覆盖的信息，比如核保信息、理赔信息、增值服务信息。它还会 review 已经形成的报告或上下文，发现缺口之后按需编辑。这个角色很重要，因为保险产品的用户价值往往不只在条款责任里，也在核保、理赔和服务体验里。
第三个是 World Knowledge Agent。
保险产品理解不能完全关在产品材料里。比如旅行险要理解目的地风险，高海拔徒步要理解真实场景，重疾险可能要理解疾病常识和行业表达。但这个外部知识必须受限引入，不能让模型自由发挥。所以 World Knowledge Agent 的职责是根据产品基本情况检索外部世界认知，并且只在有明确边界的时候，增加真实世界认知模块。
最后是 Verify Agent。
Verify Agent 会根据 state/VFS 中的上下文包、报告以及所有原始数据源进行打分。合格时完成回调，不合格时回调错误信息。这里的关键不是让 Verify Agent “感觉一下写得好不好”，而是让它基于产物和原始数据源做对齐。它看到的是报告，也看到报告背后的证据。
所以，上下文供给链路沉淀的是离线认知资本。它并不直接等于一个用户可见页面。在这个基础上，保险快查有两个重要的消费出口。
第一个出口是 DIPG。它是内容型消费。
DIPG 会消费上游上下文供给链路产出的认知资本，然后生成前端页面可以直接展示的对客内容，比如深度解读模块。也就是说，DIPG 产出的是 verified HTML，是一种可以被用户直接阅读、被前端直接渲染的内容资产。
第二个出口是 AgenticOne。它是交互型消费。
AgenticOne 面向的是用户实时互动。用户每一轮提问，在线 Agent 都要理解意图，调度搜品、取证、问答、核保、试算、推荐等能力，最后形成一个连续的咨询体验。所以它消费的是同一批离线认知资本，但产出的是互动体验，而不是固定页面。
展开阅读
DIPG：内容型消费
我们先讲 DIPG。
DIPG 不是孤立的离线生成系统。它很大程度上依赖前面的上下文供给链路。更准确地说，上游链路负责回答“产品知识从哪里来、是否完整、是否可追溯”，DIPG 负责把这些上下文资产转成 C 端用户可直接消费的内容资产。
DIPG 里也有一个多 Agent 闭环。
Research Agent 负责读取产品上下文和原始材料，生成深度解读 HTML。Verify Agent 负责校验 HTML 和原始数据源是否一致，也会做结构校验。Host Agent 负责编排整个过程，并在校验不通过时根据 fix_hint 精准修正，而不是让 Research Agent 全盘重写。
为什么不能让实时生成直出？我们踩过两个典型问题。
一个是渲染问题。比如 HTML 末尾多了一个孤儿 </div>，单看文本很难发现，但进入移动端容器后会导致页面结构错乱。
另一个是事实幻觉。比如报告里写“优于市场 85% 同类产品”，页面看起来很漂亮，但原始材料里根本没有任何市场排名或百分位数据。这种问题比渲染问题更危险，因为它不是页面坏了，而是页面在用很确定的语气说一个没有依据的事实。
所以 DIPG 的 Verify Agent 必须看得到生产原料。我们通过 /audit/ 或对应的 state 记录生成过程中用过的素材、工具调用和检索结果。这样校验就不是对 HTML 做语言分析，而是对“HTML 里的结论”和“原始数据源”做事实对齐。
当 Verify Agent 发现问题后，会返回结构化的修正建议。Host Agent 只按这些建议做局部 patch。通过后再回调下游，刷入 DB，按产品开启。用户打开保险快查详情页时，看到的是已经通过校验的离线产物，而不是现场赌一次模型生成。
这就是 DIPG 的定位：它把离线认知资本转化成可被前端页面直接展示的对客内容资产。
展开阅读
AgenticOne：交互型消费
接下来讲 AgenticOne。
如果说 DIPG 是内容型消费，那么 AgenticOne 就是交互型消费。它不是生成一份固定内容，而是在用户每一轮实时提问时，调度离线认知资本、工具和业务流程，形成一个可持续互动的咨询体验。
在线系统面对的问题和离线不同。离线关心的是“如何生产一份合格内容”。在线关心的是“用户这一轮到底想干什么，以及应该调度哪个能力”。
所以在线主 Agent 必须做薄。它负责理解用户意图、判断下一步该搜索、取证、问答、推荐、核保、试算，还是进入某个子流程。但它不应该亲自吞长条款，不应该自己拼复杂搜索参数，也不应该在终末工具已经生成结果后再随手改写。
比如搜品不是一个普通搜索工具。用户说“端午去尼泊尔爬山”，主 Agent 会把它转成更结构化的搜索任务，交给搜品子图。搜品子图再把任务拆成产品搜索、核保过滤、预算过滤、责任过滤等，并发执行，最后输出候选产品和命中原因。
再比如条款问答。用户问“EBC 徒步能不能赔？”系统不能让主 Agent 凭印象回答。正确链路是先由取证 SubAgent 查条款、除外责任、投保须知，把证据写入 state.search_evidence。主 Agent 只知道证据准备好了，然后调用 qa_summary 读取证据并生成最终答案。
这里有一个很重要的原则：长证据进 state，不要进 messages。主 Agent 不背长条款，只负责任务调度。真正解释证据的是终末工具。
终末工具也要被保护。推荐报告和条款问答这种工具，本身已经生成用户可见内容。如果成功后再让主 Agent 总结一遍，就容易破坏格式、丢失证据、改写结论，甚至制造新的幻觉。所以终末工具成功后应该直接成为最终输出。
最后是流式输出。
多 Agent 系统内部事件非常复杂。主 Agent、搜品子图、取证 Agent、工具调用、裸 LLM 调用，都会产生事件。如果按事件到达顺序直接展示，用户看到的就是一堆乱序的系统噪音。
所以在线系统需要事件层。内部通过 astream_events 监听运行时事件，再由 producer 按 checkpoint、run_id、parent_ids 分组进入队列，consumer 再按业务顺序翻译成前端 SSE。用户看到的是搜索、取证、生成答案这样的业务时序，而不是底层执行树。
展开阅读
收束
到这里，我们可以把保险快查的 Agent Native 实践总结成一张图：
上下文供给链路
-> 沉淀离线认知资本
|
|-- DIPG：内容型消费，产出可直接展示的对客内容资产
|
'-- AgenticOne：交互型消费，产出可持续互动的实时咨询体验上下文供给链路先把分散的产品材料和外部知识沉淀成离线认知资本。DIPG 消费这些资本，生成可直接展示的对客内容资产。AgenticOne 消费这些资本，生成可互动消费的实时咨询体验。两者共同构成保险快查在 Product Plane 上的 Agent Native 实践。
最后回到方法论。
第一，用 OneAgent 构造足够强的基础智能体。不要为每个业务从零搭一套孤立系统，而是基于统一的基础能力派生领域 Agent。
第二，用协议化协作模式约束多 Agent。任务怎么定义，状态怎么交接，证据怎么留存，产物怎么校验，事件怎么输出，都要有工程契约。
第三，把离线认知资本作为产品智能的底座。在线体验的上限，很多时候由离线沉淀的上下文资产、证据资产和内容资产决定。
第四，在线系统不要试图让一个大 Agent 做所有事情。主 Agent 要薄，领域能力要厚，长上下文要进 state，终末产物要保护。
所以最后我想用一句话收束：
构建 Agent Native Product，不是让模型在线上想得更久，而是让系统持续沉淀可复用、可追溯、可校验的认知资本，并用协议化的多 Agent 协作，把这些资本稳定地交付给用户。
这也是保险快查这套实践给我的最大启发。
展开阅读