以产品调研为例，拆解垂直 Agent-First 产品的6个设计理念
一边是 Coding Agent 和通用 Agent 发展得如火如荼，一边是”SaaS 已死”被大谈特谈。这段时间在 AI Coding 的时候，这个问题一直萦绕在心头：未来垂直领域的 Agentic First 产品还会有出路吗，应该怎么做？
Codex 和 Claude Code 这类 Coding Agent 已经证明了一件事——Agent 接入代码仓库之后，能跑测试、能记住项目约定、能跨会话读取上下文、能跨时间沉淀记忆，“越用越聪明”是真实的。Claude 的 Cowork 模式也是同一个方向：它能接入你的文件系统、不断积累记忆、调用浏览器、终端和外部工具，Agent 不再是聊完就走，而是真的开始在你的工作环境里埋头苦干。
但这些都是通用或编程场景。到了一个具体的垂直业务领域，Agent 的输出靠什么结构积累起来、越用越值钱？这个问题是否还值得讨论？
就这样，我边做边学，大致整理出了 Agentic Asset Loop 这个思路，也在离我最近的”产品调研“这个场景做了一场实践。
这个产品调研的工具，帮产品经理持续理解一个产品，跟着它一起演化。为什么选这个场景？竞品调研是产品经理的日常工作，够垂直、够聚焦，先不碰复杂的业务流程、权限和多人协作——只是用来验证一件事：Agentic 产品的设计理念在非 Coding 的垂直领域怎么落地？
目前跑着 5 个产品空间（Dify、Linear、Manus、Notion、钉钉悟空），其中 Dify 已经做到了第 5 轮增量研究，积累了 57 条有证据支撑的产品判断。
这篇文章不是产品宣讲。我想聊的是做这个东西过程中碰到的 6 个设计决策——如果你也在想怎么做 Agentic 产品，不管在什么领域，可能会觉得有点意思。
1 在你的领域里，Agent 输出的”确定性单元”应该是什么？
这是我碰到的第一个、也是最重要的设计问题。
Agent 每次跑完，产出的是一整段内容——你没法对其中某句话单独追溯来源、更新状态、标记置信度。即使有引用、有记忆，这段内容作为一个整体，没法被拆开来管理。
传统 SaaS 能跑起来，核心就是做了数据建模——把混沌的信息拆成可操作的最小单元。CRM 里是销售线索，Excel 里是单元格。有了这个单元，才有数据的生产、处理和消费，整个产品才转得动。
Agent 产品要让输出”活”起来，也得做同样的事——定义你这个领域里的”确定性单元”，一个能单独拎出来说”这条是什么、对不对、怎么进化”的最小知识单元。
在代码领域，这个单元天然就有：一个函数、一个测试用例、一次 commit。写完跑一遍测试就知道对不对，有明确的反馈。
在产品调研这个场景中，我最初的直觉是用”文档摘要”作为核心对象——让 Agent 读完资料生成结构化的摘要，存起来。但很快发现不行：摘要丢了证据链（某个判断依据是什么你不知道），而且没法增量更新（新信息来了只能重新生成）。
考虑到调研的目的是观察和判断，我选了 判断 + 证据——一条有明确立场的判断，加上支撑它的证据。判断可以被验证、被反驳、被更新。
一条 Claim 长什么样？以 Dify 产品空间为例：
“Dify 定位为 Agentic Workflow Builder（智能体工作流构建器），是一个面向团队的开源 AI 应用开发平台。”
这条 Claim 不只是一句话。它带有：
- 类型：这是一条”官方表述”（来自官网），跟”推断”或”假设”不同
- 置信度：高——直接来自官方定位描述
- 证据：1 条，指向 dify.ai 官网的具体快照
- 审核状态：自动审核——高置信度自动审核
57 条这样的判断，按”定位与市场”（20 条）、“定价与商业”（11 条）、“产品与功能”（6 条）等维度归类，构成了 Dify 这个产品空间的认知骨架。
内容本身是一样的，为什么判断比 AI 摘要更适合作为确定性单元？因为它可以被单独操作：
- 当 Dify 更新了定价策略，相关的判断可以被标记为”可能过时”，而不需要重写整篇调研报告
- 当 PM 认为某条推断不够准确，可以把它的置信度从”高”调到”中”，或者标记为”有争议”
- 当新一轮研究发现了矛盾信息，可以创建一条新判断标注为”与 claim-xxx 冲突”
每条判断的证据链接到具体的信源和快照。这里的信源不只是一个 URL——它记了这个来源是什么性质（官网？帮助文档？博客？定价页？）、优先级多高、上次检查是什么时候、内容有没有变过。
不断尝试的过程中，也抽象出了 Agentic Asset Loop 中的一个原则，就是 Evidence-backed：一条产品认知必须由”判断 + 证据 + 运行记录“三样构成，缺一个都不算数。
判断的质量取决于 Agent 的分析能力。事实型判断（“Dify Cloud Service Professional 版 $59/月”）基本靠谱，因为信息是明确的。推断型判断（“Dify 正在从个人工具转向团队协作”）则需要 PM 的判断来确认——Agent 做的是把散落在更新日志、博客、帮助文档里的信号综合到一起，最终判断还是人的事。
有人可能会问：这跟”爬虫 + 结构化知识库”有什么区别？
单次运行来看，区别确实不大——Agent 扫完信源生成一批判断，跟 AI 摘要工具差不多。差别在于时间的魔法。
第 1 轮研究生成了 30 条判断。第 2 轮增量运行时，Agent 带着这 30 条已有判断去看新信息，新发现融进已有框架里。每轮结束后 Agent 还会写一段”执行复盘“，前几轮积累的开放问题和探索性判断也会变成下一轮的小目标——Agent 带着”上次没想明白的事”继续挖。
到了第 5 轮，57 条判断里有第 1 轮就有的，有第 3 轮新增的推断，有第 5 轮才验证的。5 轮下来长出来的是一个持续演化的认知结构，不是 5 份独立报告摞在一起。
这就是标题里说的”复利”——不是每轮产出翻倍，而是每轮的产出会变成下一轮的起点。第 1 轮的 30 条判断是第 2 轮的上下文，第 2 轮的修正是第 3 轮的基础。轮次越多，Agent 看新信息时的视角越丰富，发现新洞察的边际成本越低。
爬虫 + 知识库做的是”内容更新”：检测到网页变了，重新抓取存储。这里做的是”认知升级”：内容变化会关联回已有判断，触发判断的状态更新、置信度调整、甚至产生新的开放问题。底层技术大致是一样的，但上层的产品逻辑不同。
总之，判断的价值要在多轮增量之后才真正体现——它给了系统一个可以持续长东西的骨架。
2 Agent 的输出怎么”活着”？
有了判断和证据，接下来的问题很自然：这些东西怎么组织起来，变得为 PM 所用？
这里给每个产品空间做了九个知识页：概览、产品定位、用户画像、工作流、功能地图、帮助文档、商业模式、时间线、开放问题。基本上就是一个 PM 理解竞品时会问的那些问题。
知识页不是写完就不动的”死文档“。Dify 的功能地图上标着”第 5 轮复查（2026-05-19）“，右侧目录中多处标记”本轮新增”。时间线页跨越了 2023 到 2026 年，每条事件都标注了来源——这不是一次写出来的，是跑了五轮一点点攒出来的。
我把这个环节称为 Output-as-view：底层的判断 和证据是资产，知识页是从它们聚合出来的视图，目的是方便人类浏览、分发。每次知识页变更时，系统会保存 before/after 快照，关联到触发这次更新的 Claim 和信源。你可以追溯”这段话是哪次研究运行写的，依据了哪些证据”。
除了单产品的纵向知识页，还有进一步的跨产品、按主题的主题报告，目的是为了更好的”内容消费“。比如”Manus 与 Notion 异同对比”，引用了 2 个产品空间的 8 条已有判断，按 5 个维度展开比较。
这就是我说的资产复利——两个产品空间各自攒了几十条判断之后，做跨产品对比不用从零开始，直接从已有资产里聚合就行。积累越多，新分析越省力。图中虽然只做了 1 个主题报告，“复利”还没真正跑起来，但方向是对的。
3 没有编程的测试套件，怎么知道 Agent 跑得对不对？
Codex 写完代码可以 npm test，结果好不好有明确反馈。产品调研的 Agent 跑完一轮，谁来判断结果质量？我目前的回答是：无法绝对验证结果正确与否，至少让过程可追溯。 产品在每次研究运行都有完整的研究运行记录。
一次运行历史记录的是 PM 能看懂的审计信息（暂且称为 Run-traceable）：
- 这次研究的目标（“增量复查 Dify 帮助文档、更新日志、定价页变化”）
- 检查了哪些信源、哪些有变化、哪些抓取失败
- 产出了多少条新判断、更新了多少条旧判断
- Agent 对这次运行的复盘（每轮结束后 Agent 会写一段复盘，说自己做得怎么样、遗漏了什么）
这种过程追溯对不同类型的历史判断帮助各有不同。
- 对于事实型判断（“Dify Cloud Service Professional 版 $59/月”），追溯到来源页面就能验证，价值很直接。
- 对于推断型判断（“Dify 正在从个人工具转向团队协作”），追溯能告诉你 Agent 读了哪些页面、看到了什么信号，但最终判断是否合理还是需要 PM 自己来。
换句话说，事实类判断追溯之后接近”可验证”，推断类判断追溯之后只是”可审计”——审核成本降低了，但审核本身省不掉。
增量研究：不是每次重头来
另一个更实际的机制是增量研究。每次增量运行前会做一次”预检“：重新抓取所有已跟踪的信源，跟上次快照比对，只把变化了的内容交给 Agent。所以 Dify 的第 5 轮研究不用重新看所有 33 个信源——系统先筛出哪些变了，Agent 只关注这些变化对已有判断的影响。
增量的关键不是检测”哪个网页变了”——爬虫就能做——而是把内容变化关联回已有的判断：变化影响了某条判断？标记”可能过时”，生成”重要变化“推给 PM。这就是前面说的”认知级增量”落到实现上的样子。
4 怎么控制 Agent 的研究行为？
现在主流 Agent 普遍在引入记忆、Skill、 上下文这些控制手段。本质上，垂直领域要做的也是这些事情——只不过如果把这些机制”翻译“成垂直用户能直接理解的语言，使用体感可能会更好。用户可以不理解 Skill、上下文，只需要关注具体的研究方法、研究过程和报告输出规范就行。
也就是把技能、系统提示词变成结构化的显式配置。举个例子：我近期更关注 Dify 的商业化进展——最近他们推了 Premium 方案和云服务分层定价，我想知道定价策略、目标用户群和跟开源版的差异化。在产品里只需要这样配：
在个人偏好里，我把”定价包装”和”商业模式”设为高优先关注维度，“上手流程”暂时降低优先级。在来源策略里，我把定价页和博客/更新日志设为主来源并开启持续跟踪，访谈和第三方文章设为补充来源。在研究能力里，“定价与商业模式分析”保持开启，“帮助文档地图构建”这次可以关掉——不需要 Agent 花时间爬帮助中心。然后选择”增量跟踪”这套研究流程发起运行。
这样 Agent 跑出来的结果就会聚焦在定价和商业变化上，而不是面面俱到地重新扫一遍所有维度。下次如果我的关注点变了——比如 Dify 发布了新的工作流功能，我想看产品能力变化——调整几个配置项就行，不需要重新描述整个研究上下文。
上面提到的研究能力、来源策略、研究流程、个人偏好只是关于”如何研究“的配置项。更好的控制 AI 的产出，还包括 AI 研究能力（比如是否允许浏览器采集、是否写入知识库）、输出设置（语言、术语风格、事实和推断怎么区分）等等。
这些配置注入每次研究或会话的上下文，PM 不用写重复的提示词，勾勾选选就行。我把这个设计叫 Human-calibrated——人在事前就定好 Agent 的方向和边界，而且配置是持久的，设一次后面每轮都按这个来。
5 当 Agent 越跑越多，人审核不过来怎么办？
这个问题还没有终极的方案。
目前的做法是每次研究跑完后自动生成关注项——简单说就是一个”这次有什么值得你看的”的清单：哪些信源变了、哪些判断可能过时了。
而审核队列则汇总了所有产品空间的待办事项，人工扫一眼就知道该看什么，处理完的标记掉就行。
目前 5 个产品空间累积了 72 条待处理、5 条待复查、4 条已审核。说白了，连我自己都没审完。 72 条其实还扛得住——每条花 2 分钟，2.5 小时清完。但产品空间涨到几十个、Agent 持续跑增量的时候，待审核项会翻好几倍。到那时候纯靠人审就不行了。
这可能是做垂类 Agent 产品最根本的张力：Agent 的执行量可以无限扩展，但人的判断带宽有上限。 Codex 的 code review 至少有明确的 diff 边界（改了什么一目了然），但”这条关于 Dify 商业化策略的判断是否准确”需要 PM 的专业经验，没法简单自动化。
当前的做法是按置信度和证据充分度分层——证据硬的 Claim 降低审核优先级，弱证据或推断型的优先推给 PM。但这只能缓解，不能解决。
前面第 4 部分提到 Human-calibrated——人校准 Agent 的方向和边界。但”持续校准”说起来容易，人的精力是有限的，这才是这套逻辑能不能规模化的最大瓶颈。
这个问题目前只有一些初步思路——比如用置信度分层做自动审核、让审核策略本身也能随信任积累演化，但还有待实际验证。
6 会话：Agent 产品里绕不开的交互界面
前面 5 个部分讲的都是”资产怎么建、怎么长、怎么管”。但回到日常使用，人和系统打交道的主要方式还是保留了对话——打开一个对话框，用自然语言告诉 Agent 该干什么。这是当前几乎所有 AI 产品的主交互形式，垂直 Agent 产品也不例外。
会话本身不是资产，但它是与人连接的入口。一次”帮我看看 Dify 最新的定价变化”的会话，背后触发的是一整套研究流程：信源抓取、判断生成、知识页更新、关注项推送。会话结束后，价值沉淀在判断和知识库里，会话本身成为一个会话历史。
当然”会话”不代表不需要管理。实际使用中，会话历史承担着几个容易被忽略的功能：
- 回溯上下文。 两周前跑了一次 Linear 的调研，结果里有个奇怪的判断。想知道当时的指令是什么、Agent 怎么理解的——翻会话历史比翻研究运行记录更直观，因为它保留了人和 Agent 之间的完整对话脉络。
- 积累记忆。 用户会逐渐形成自己的提问习惯——“先看定价页变化，再对比上轮判断，最后给我三条关键变化”。这些模式藏在历史会话里，”记忆机制“能把这些沉淀到”个人偏好“中。
- 区分会话的生命周期。 有些会话是一次性的快速提问，用完即弃；有些是重要研究任务的触发记录，值得保留；还有些已经过时了，应该归档清理。
这里没有太多”创新”可言——会话管理在 ChatGPT、Claude 等产品里已经是标配。但在垂直 Agent 产品里，关键在于会话和资产之间的联动：一条会话触发了哪些判断的更新？一次研究运行是从哪个会话发起的？如果能把会话和它产生的资产变更串起来，会话就不只是聊天记录，也是资产演化的操作日志。
总之，方向是明确的：会话是手段，资产是目的。 会话管理的核心不是让聊天记录更好看，而是让”从对话到资产沉淀”这条链路更透明、更可追溯。
写在最后
回到开头的问题。 Claude Code、Codex 证明了 Agent 产品在编程领域能大放异彩；Manus 这类通用 Agent 什么都能做，但仍然不够聚焦。目前我想试的是：在一个垂直领域，让 Agent 能发光发热，输出能留下来、能长在之前的基础上、能成为时间的朋友。
尝试到现在，最大的感受是：难题大多不在 AI 能力上，而在新的产品架构上。 模型会越来越强，但 Agent 输出什么形态、怎么随时间演化、人在哪个环节介入——这些不会因为模型变强而自动消失。让 Agent 的输出从”一次性的报告”变成”越用越值钱的资产”，需要的不是更强的模型，而是一套让产出能积累、能关联、能被人校准的产品框架。
以上只是我在产品调研这个小众场景中尝试给出的一种回答，还很粗糙。但我觉得这些问题本身仍然值得探讨——你的领域里，Agent 的确定性单元是什么？没有自动验证机制的时候怎么做追溯？人就那么多精力，怎么不被 Agent 的爆炸式产出淹没？
如果你也在想这些问题，或者在其他垂直领域有不同的解法，很想听听你的思路。欢迎进一步沟通。