之前的文章中，整体介绍了 Agentic Asset Loop 这个设计理念，其中提到了 5 个设计原则。在实践过程中，发现这几个原则单独看每条都合理，但真正试着同时满足它们的时候，会发现它们之间会争抢资源、互相矛盾。但这反而让它们有用——你在具体的场景中必须做出取舍，而取舍的过程就是每个设计者“仁者见仁、智者见智”的地方。
这篇我们先逐条拆开，讲讲每条原则在约束什么、没有它会怎样、落地的关键是什么。下一篇讲它们之间互相打架。
原则一：Asset-first（资产优先）
约束的是”沉淀”环节：重要结果必须沉淀成结构化的业务实体。
这条原则看起来最好理解，但也最容易被做歪。
先承认一个事实：今天的 AI 产品在”留下点什么”这件事上已经比一年前好很多了。ChatGPT 可以生成文件并导出，Claude Code 和 Cursor 直接绑定文件系统对文件做增删改查，其他通用型 Agent 产品也在通过 Skill 接入或对话中直接定义结构的方式来管理和定义产出物。
所以 Asset-first 真正要讨论的问题是：留下的东西是否结构清晰、可复用、可回溯。
当前通用 Agent 的能力可以粗略分成三层。Memory 记录”我经历了什么”，存用户偏好和历史摘要。Soul 定义”我是什么样的存在”，管角色或人设的设定和行为边界。Skill 则定义”我知道怎么做某件事”，包括方法、流程和输出结构。其中 Skill 离“资产”这个概念最近——不断打磨之后，确实可以让输出结构规整、判断附带来源和置信度，逼近一个结果态的资产。
但 Skill 管的是”怎么生产资产”，不管”资产生产出来之后怎么活”（当前现状看来）。3 件事它做不到：
- 增量关系（不知道上次产出了什么，这次该在哪些判断上做增量、哪些该标记过期）——实践中 Skill 可以通过读取已有文件来变通，但这靠具体设计，不是 Skill 抽象层本身的能力；
- 过程追溯（不记录每次执行的决策路径，执行完就丢失）；
- 跨运行的校准反馈（人的校准动作不会反哺到下次执行的逻辑中）。
Asset-first 补的就是这一段：资产的生命周期管理——从产出、存活、关联、更新、校准到过期。 如果未来某个通用 Agent 平台把 Skill 的产出接入了持久化的资产层，支持这些能力——那它就是在做 Asset-first，不管它叫不叫这个名字。
没有这条原则会怎样？ 东西留下了，但没法被系统性地复用和迭代。哪些分析还有效、哪些该更新、哪些跟其他分析有关联——全在人脑子里或会话记录里，不在产品里。Agent 跑得越多，这些散落的产出就越像一个没有索引的仓库——存了很多东西，但找到和用上的成本越来越高。
落地的关键： 定义清楚资产类型和入库标准。什么算资产、什么不算，必须有明确的判断。不是 Agent 产出的所有东西都值得沉淀，否则资产库很快变成垃圾场。当然矫枉过正就是反过来——标准定得太严，只有”完全确认”的结论才能入库，结果大量有价值的中间判断被挡在外面，资产库干净但空。
原则二：Evidence-backed（证据驱动）
约束的是”可信”环节：每个判断必须能回答——证据在哪、来源是什么、什么时候采集的、置信度多少。
这条原则当然跟防幻觉有关，但光防幻觉不够。它真正的价值是让资产变得可审计、可校准。
如果一个产品判断没有证据链，人面对它只有两种选择：全信或者全不信。有了证据链，人可以判断”这个结论的第二条依据过时了，需要更新，但其他三条依据还成立，所以结论大方向没问题，置信度从高调到中”。
最小信任单元是三个东西绑在一起：Claim（判断）+ Evidence（证据）+ ResearchRun（产出这条证据的那次运行）。三个缺一不可。只有“判断”没有“证据”，用户没法判断该信多少。有“证据”但不知道是哪次运行产出的，无法追溯当时的上下文和方法是否可靠。
用产品调研场景举个例子，让这三个概念变得具体。
假设你在用一个按 AAL 思路设计的产品研究工具，持续跟踪 Notion 的 AI 功能演进。一条资产在系统里长这样：“判断”是”Notion 已将 AI 搜索从独立入口整合进全局搜索栏”，置信度标记为”高”。绑定的“证据”是 Notion 帮助文档中搜索功能页面的一段描述，附带原文快照和采集时间（2025-03-15）。关联的“执行记录”追溯了这条证据是在哪一次调研中被发现的——当时的目标是”更新 Notion AI 功能地图”，Agent 一共扫描了 12 个来源页面，这条证据来自第 7 个。三个信息绑在一起，产品经理看到这条判断时可以一路追溯：结论从哪来的、原始信息长什么样、当时的调研覆盖了多大范围。能查到这些，信任才有基础。
没有这条原则会怎样？ 资产库会变成一堆”AI 说的结论”。用户不知道该信多少，也不知道错了该从哪里纠——是来源过时了、推理有跳步、还是前提本身就有问题？没有证据链，这些问题全部退化成同一个问题：你信不信 AI。最后要么闭着眼信，要么干脆不用。
落地的关键： 不是所有判断都需要同样强度的证据。一方面，事实型的判断（“Notion 在 2025 年 3 月上线了 AI 搜索功能”）需要明确来源和快照。而推断型的判断（“Notion 的 AI 战略正在从单点功能走向平台化”）则可以接受弱证据加高权重的人工校准。为每种判断匹配合适的证据要求，是这条原则能不能落地的关键。当然也不能对所有判断一刀切——要么全部要求强证据（探索型判断直接被卡死），要么全部放松（事实型判断的可信度坍塌）。
原则三：Run-traceable（运行可追溯）
约束的是”运行”环节：每次 Agent 执行都要有运行记录，它是审计账本，不是底层日志。
这条原则最容易被误解为”加个 log”。要说清楚运行记录是什么，先看看传统产品里的日志分几层。
传统产品的日志体系。 传统软件系统里，日志至少分两层。一层是运维日志（ops log），记录技术层面的事件——API 调用、服务响应时间、错误栈，受众是工程师，目的是 Debug。另一层是业务日志（business log），记录业务层面的关键动作——订单提交、审批流转、合同状态变更，受众是业务人员和审计团队，目的是追溯业务操作。大多数成熟 SaaS 两层都有，操作审计日志本身就是合规要求。
Agent 的运行记录是什么。 运行记录跟上面两层都不一样。它记录的不是系统级事件，也不是用户的操作动作，而是 Agent 在一次任务执行中的完整决策过程——拿到目标后做了什么规划、查了哪些来源、跳过了哪些以及为什么跳过、在哪些判断上犹豫过、最终得出了什么结论。它的受众是业务人员和审核者，目的是理解一次 Agent 执行”怎么做的”和”为什么这么做”，而不只是”做了什么”。
用一个比方：运维日志是车载电脑的传感器数据，业务日志是行驶里程和加油记录，运行记录是行车记录仪。前两个告诉你车的状态和资源消耗，第三个告诉你司机走了哪条路、为什么在路口左转而不是右转。
当前通用型 Agent 在这方面做了一些尝试。Claude 和 ChatGPT 有了 memory 机制，能跨会话记住关键信息。Claude Code 会维护会话上下文和工具调用记录。但这些更接近”记住了什么”，不是”这次任务是怎么做的”。这条判断是在什么上下文、基于什么信息、通过什么推理路径得出的？这个问题 memory 和 context 窗口都答不了，运行记录才答得了。
没有这条原则会怎样？ Agent 变成一个黑盒。结果好的时候没人在意，结果不好的时候没法排查是目标定错了、来源选错了、还是推理出了问题。更要命的是，没有运行记录，其他原则也跟着瘫痪——你没法把证据追溯到具体的运行，人也没法基于执行过程做校准。
落地的关键： 粒度选择是最大的挑战。太粗等于没记，太细没人看。一个可行的做法是按决策点记录：Agent 执行中的每个重要选择（选了哪条路径、跳过了什么、置信度是多少）构成骨架，细节按需展开。最常见的错误方向是把运行日志做成了运维日志——技术团队觉得记够了，业务人员打开一看全是 API 调用和 token 计数，完全不知道 Agent 做了什么判断。
原则四：Human-in-the-loop（人在环路）
约束的是”校准”环节：高影响动作必须经人确认，但不是每一步都要人看。
这条原则要同时防两种错误倾向。
- 第一种是人完全不介入。Agent 全自动运行，结果直接入库或对外输出。错误会在自动化链条上被放大：一份有问题的研究报告发给了客户，一条错误的合同审查意见影响了谈判策略——这些问题不会自我纠正，只会静默积累。
- 第二种是人介入每一步。Agent 变成了一个需要不断点”确定”的弹窗。人的注意力被消耗在低价值的确认上，疲劳之后反而更容易在真正重要的判断上犯错。
正确的设计是按影响程度分级。4 类高影响动作必须经人确认：修改核心判断、删除已有结论、提升置信度等级、生成对外输出。其他的让 Agent 自主执行，异常时触发审核。
更进一步，人不一定是唯一的审核者。在执行 Agent 和人之间可以加一层审计 Agent，做前置质量过滤。但要对审计 Agent 的能力边界诚实：检查证据链是否完整、来源是否过期，这些是结构化规则可以覆盖的，当前就能做。而”新判断跟已有资产是否矛盾”则是一个难得多的问题——两条判断在什么条件下算矛盾，往往取决于语境而非字面意思，这更接近语义理解而非规则匹配，短期内审计 Agent 在这个维度上只能做粗筛，不能替代人的判断。认清这条能力边界，才能合理设计审计 Agent 的职责范围，而不是把它当成省事的万金油。
把这个思路再往前推，HITL 其实有一条自己的演化路径：
- 早期：人审核
- 中期：置信度分层 + 审计 Agent 做前置过滤
- 后期：人从”逐条审判断”变成”审核审计策略”——不是看每条判断对不对，而是看审核标准是否合理、漏判率是否可接受
人的角色沿一条线持续上移：审核内容 → 审核规则 → 审核审核规则的规则。每上移一层，人的单位注意力撬动的系统质量上一个数量级。不过要承认，前两层在产品里有明确的操作含义——审核一条判断、调整一个阈值——第三层目前更接近一个推演出的方向，它在产品里具体长什么样，可能要等前两层跑通之后才能看清楚。
没有这条原则会怎样？ 系统要么不可信（全自动，错误静默积累），要么不可用（全手动，审核负担压垮使用意愿）。而且没有人的校准信号进来，系统的判断质量没有自我修正的机制——错不会越来越少，只会越来越一致地错。
落地的关键： 审核队列的设计比审核动作本身更重要。什么进队列、怎么排优先级、超时怎么处理、审核结论怎么反哺给执行 Agent 和审计 Agent。更关键的是，审核队列的抽象层级要能跟着人的角色上移走。最容易出问题的地方是审核疲劳——队列里低优先级的判断积压太多，审核者为了清队列开始批量通过，高影响判断混在里面被一起放过去了。
原则五：Output-as-view（输出即视图）
约束的是”输出”环节：报告、摘要、图表都是资产的视图，不是事实来源本身。
前面 4 个原则在于“Agent 怎么跑”，而这条原则说的是“用户怎么用”。
传统做法是 Agent 生成一份报告，用户在报告上修改、批注、分享。报告就是最终产物。问题在于，一旦用户改了报告，报告和底层资产基本上就脱节了。下次 Agent 重新生成报告，要么覆盖掉用户的修改，要么两边不一致。这个问题在今天的 AI 产品里已经很常见——用 ChatGPT 生成一份分析报告，手动改了几处结论，下次让它更新，要么从头生成一份全新的（之前的修改白做了），要么你得手动告诉它哪些改了哪些没改（回到了人工维护的老路）。
Output-as-view 力图换一种思路：报告不是事实来源，资产才是。报告只是资产在某个时间点、面向某个受众、按某种格式的一次展示。用户想修改结论？修改应该回写到资产层的对应判断上，而不是改报告里的文字。这样，无论之后以什么格式、给什么人看、在什么时间点生成，输出都基于同一套最新的、经过校准的资产。
用数据库的类比最直接：资产是表，报告是视图。你不会直接改视图里的数据，你改表，视图自动更新。
这条原则连带改变了用户跟产品打交道的方式。报告是最终产物的时候，用户操作的是”文档”——打开、编辑、保存、分享。报告变成视图之后，用户操作的对象变成了”资产”本身——审核判断、调整置信度、标记过期、触发更新。报告退化成一个按需生成的东西，这也符合当下 AI Coding 即时生成 HTML 文件的趋势。
没有这条原则会怎样？ 报告和资产两张皮。改了报告底层没变，更新了底层报告没跟上。时间一长没人知道哪个版本是准的。而且报告一旦成了事实来源，资产层就名存实亡——判断和证据都藏在一份份文档里，没法被系统检索、关联和增量更新。
落地的关键： 用户修改输出时，系统需要识别这是”样式调整”（不影响资产）还是”判断修正”（需要回写资产层）。这个区分是整个循环能不能闭合的关键接缝，难点在于同一个修改动作可能横跨两者——用户把”Notion 正在走向平台化”改成”Notion 在 AI 层面正在走向平台化”，这是在收窄判断范围还是在调整措辞？可能的方向有两种：一种是在修改时让用户显式选择”改表达”还是”改结论”，简单但会增加操作负担；另一种是系统根据修改涉及的语义范围自动归类，再由用户确认，体验更好但技术门槛高。这个问题目前没有成熟方案，也是后续实践中需要优先验证的设计瓶颈。
五条原则到这里讲完了。单看每条都合理，但实践过程中试着同时满足它们又会发现麻烦重重——想快速沉淀资产，审核就跟不上；想证据完备，执行效率就上不去。
下篇展开讲讲这些原则之间“左右互搏”的地方，这才是真正的“深水区”。