上篇文章对 Agentic Asset Loop 的 5 条设计原则做了逐条拆解。这篇谈一个延伸出来的复杂问题：它们之间如何协作。
一套好的设计原则不应该是 5 个独立的、正确的口号——每条都对、放一起也不冲突，那就是说了等于没说。有用的原则之间会争夺资源、逼你做取舍，这才真正体现你的”产品品味”。
冲突一：Asset-first vs Human-in-the-loop
Agent 量产判断，人审不过来。
Asset-first 要求 Agent 的产出持续沉淀为结构化资产。Human-in-the-loop 要求高影响的判断必须经人确认。当 Agent 的执行量上去之后，这两条原则会正面冲突：Agent 一天能跑 200 个研究任务，每个任务产出 10 条判断，一共 2000 条判断等着入库。人一天能审多少？保守估计 50 条吧。
严格审核，资产沉淀被人的带宽锁死，增量循环转不起来。放松审核让 Agent 自动入库，没人把关，沉淀的就不是资产而是数字垃圾。
可能的解法是用置信度做分层。
- 高置信度的（证据充分、来源可靠、跟已有资产一致）自动沉淀，不进审核队列。
- 低置信度的进审核队列等人确认。
- 中间地带先入库标记”待确认”，人可以批量审核。
Claude Code 的权限模型就是类似的思路——读文件自动执行，写文件要用户批准，用户还能手动调高特定操作的信任阈值。核心逻辑一样的，按影响程度动态分级，分级标准随信任建立而调整。
不过 Claude Code 管的是操作级别的审批——要不要写这个文件。AAL 需要的是判断级别的——要不要信任这个结论。一条判断的影响取决于它在资产网络中的位置、被多少下游判断依赖、会不会改变已有的结论链，比”这个命令有没有副作用”难评估得多。
还有一层容易忽略的：置信度阈值本身也需要校准。初期偏保守，随着审核记录积累逐步放宽。换句话说，人在校准资产的同时，也在校准系统对自身判断能力的认知。
所以这套分层机制不是上线时配好就完了——阈值会随信任积累不断调整，审核架构本身也需要跟着演化。
冲突二：Evidence-backed vs 执行效率
证据要完备，但搜集证据要花 token 和时间。
合同审查中一条关键条款的风险判断，证据链不完整可能导致几百万的损失——这种场景值得花代价。但初步筛选阶段的快速判断呢？要求完整证据链就是过度设计。
解法是区分判断类型，匹配不同的证据强度。
- 事实型判断需要强证据（来源 URL、时间戳、快照）。
- 推断型判断可以接受多条弱证据交叉印证。
- 还有一类更模糊的——探索型判断。这类判断在做出的时候，现有信息就是不够充分，硬凑证据反而制造虚假的确定性。比如，“这个市场可能存在某个机会”、“Notion 可能在下半年开放 AI API”。
所以资产库里不应该只有”已确认的结论”，还应该有”不确定但值得追踪的假设”。这就引出了假设型资产这个概念：
提出假设 → 设定观察条件（什么信号会证实或证伪它）→ 后续运行自动检查 → 证实则升级为判断型资产，证伪则标记否决。
举个例子。用 Manus 做行业分析，报告里有一条判断：“东南亚跨境电商的物流基础设施可能在未来 12 个月内出现整合”。当下有一些初步信号——几家物流公司的融资动态、平台政策变化——但远不足以下定论。如果这只是静态 PDF 里的一句话，它要么被过度当真，要么被读完就忘。如果它是一个假设型资产，它会留在系统里，绑定观察条件，后续行业扫描自动检查有没有新的整合信号。验证成本不用在当下一次性花掉，而是分摊到未来的多次运行。
这也意味着资产库需要原生支持不确定性——“还不知道但值得继续看”应该是一种正式的资产状态，而不是被排除在库外的噪音。
冲突三：Run-traceable vs 用户体验
完整追溯意味着大量过程信息，但用户只想看结果。
全部展示，用户被信息淹没。全部隐藏，又回到黑盒。
理想的呈现方式是分层展示 + 异常触发。
默认只显示最终结论和关键决策点（比如”本次运行覆盖了 15 个来源，新增 3 条判断，更新 2 条已有判断”）。用户好奇某个结论怎么来的，展开看完整的决策路径。Agent 遇到冲突信息、跳过关键来源、或判断跟已有资产矛盾时，自动高亮提醒。
现有产品离这个理想还有距离。无论是 Manus 的操作直播面板还是 Claude Code 的内联输出展示，方向都是”让过程可观察”，但”系统主动判断什么最值得看”还没完美支持。
这背后有一个更根本的问题：什么”该记录”本身需要判断力。
一个有经验的分析师不会事无巨细地记录每一步，但他会在关键转折处做标记——“在这里我放弃了 A 来源，因为数据口径跟其他来源对不上”。这种判断靠的是对任务本身的理解。
Agent 理想状态下也该如此——在执行中识别出重要的判断节点并主动标记，而不是把每一步都记下来让人去筛。但当前 LLM 的自我反思能力还不够稳定，务实的做法是用规则先兜底——信息冲突自动标记、来源跳过强制记录原因、置信度变化超过阈值时触发记录——把自主认知作为规则之上的增强，而不是替代。随着模型能力提升，规则逐步退让，自主认知的权重逐步上升。
最终的方向当然是系统学会自己判断什么值得记——但在到达那一步之前，规则兜底比没有记录好得多。
冲突四：Asset-first vs Output-as-view
资产一直在动，但用户对输出的预期往往是稳定的。
周一你生成了一份竞品分析报告发给老板。周二 Agent 跑了一轮新的调研，更新了三条判断的置信度，标记了一条过期。如果报告是资产的实时视图，老板手里的版本已经过时了——他引用的某个结论可能已经不是当初的意思。如果报告在生成时锁定快照，报告和资产又脱节了，正好是在 Output-as-view 中要解决的问题。
这是一个版本化问题：输出在生成的瞬间应该锁定资产快照，还是永远指向最新状态？
实时指向最新，适合自己用的工作台——打开就是最新的资产全景。锁定快照，适合对外交付物——发给客户的报告、提交给管理层的周报，需要一个确定的版本。但很多场景两者都要。同一份报告，内部协作阶段需要实时同步资产变化，定稿对外发送后需要锁版本。
所以输出需要一个从实时视图到锁定快照的生命周期——编辑中跟着资产走，发布后锁定在发布那一刻的状态，同时保留”资产已更新，此报告可能需要刷新”的提示。
这套生命周期管理解决的是一个很实际的场景：用户敢不敢把 Agent 生成的报告直接发给别人，而不用担心底层资产变化让交付物悄悄”变味”。
一个还没有答案的问题
前面四组冲突的解法——Agent 产物的置信度分层、不同判断类型匹配不同的证据强度、执行过程分层展示、视图支持版本化管理——都建立在一个前提上：人的注意力是有限的，要通过各种机制把有限的注意力集中在最重要的判断上。
但如果把事情推到极致，这个前提本身也是脆弱的。
人的审核带宽是有上限的，Agent 的执行量没有上限。
当执行量从每天几百个任务增长到几千、几万个，即使人已经上移到”审核策略”层，策略本身也会随业务复杂度膨胀——判断类型在增加，边界情况在增加，领域交叉在增加。置信度分层和审计 Agent 延缓了这个矛盾，但没有消除它。
终局形态下，系统可能必须具备某种最小限度依赖人的质量保障机制——资产入库时自动做一致性自检，新判断跟已有资产是否冲突；同一个业务对象上的判断短时间内频繁变动，自动触发复查；系统定期拿已有资产去跟外部信息源比对，标记偏差。这些不能替代人的判断，但能在人看不过来的地方兜底。
这个问题没有标准答案，但值得在设计阶段就被看见。今天设计的审核框架不能是刚性的——它必须为”人参与比例逐渐降低、系统自我校准能力逐渐增强”留出足够的空间。
原则不是清单，是线索
5 条原则不是一个待办清单，勾完就算合格。它们是一组互相耦合的约束条件，每两条之间都可能产生冲突，在足够大的规模下还会碰到根本性的瓶颈。
真正的设计功力在”冲突”中生长——面对具体场景时，决定在什么程度上做什么取舍。 做产品调研和做合同管理，对证据的要求天差地别；产品初创期和成熟期，审核的松紧度完全不同；给员工用和给老板用，输出的形态也不是一回事。
框架是通用的，平衡点是具体的，当然平衡点本身也在随着规模、时间和模型进化不断移动。