Agent 怎样保持自己：事实叠加、私有坍缩与逻辑主权

上一篇讨论 Agent 到底是什么，这一篇讨论它怎样保持自己。

我越来越觉得，未来很多 Agent 的问题不是能力不够，而是能力来得太方便。大家都接同一个云模型、同一种工具栈、同一套观测面，看上去像一群在协作的智能体，骨子里却越来越像某个中心化逻辑的末梢。

如果第一篇给的是肉身，这一篇要讨论的就是主权。

一、事实不必先统一解释

分布式系统最熟悉的本能，是一遇到并发就先加锁。谁先写，谁生效；谁后写，谁等待。这个默认动作背后其实藏着一个前提：系统必须尽快承认“唯一正确状态”。

Agent 世界未必需要这么急。

更接近事实层的做法，往往恰恰是反过来：事实先叠加，不先裁决。Worker A 删除 config.yaml，Worker B 修改 config.yaml。在事实层，这不是谁对谁错，而是两条都已经发生过的记录。

graph LR
    subgraph FactStream["事实流（append-only）"]
        F1["Worker A 删除 config.yaml"]
        F2["Worker B 修改 config.yaml"]
        F3["Worker C 读取 config.yaml"]
        F1 --- F2 --- F3
    end

这点说起来抽象，落地却非常具体。工程上你完全可以把它实现成 append-only trace、事件流、OR-Set 一类的并发语义。关键不是选哪个数据结构，而是先把世界观摆正：事实不该被覆盖，解释才会冲突。

真正有决定权的，从来不是事实层，而是观察者。谁需要这个文件，谁就根据自己的目标、约束和因果历史，决定采纳哪条事实。那一步才叫坍缩。

一旦系统不再要求所有参与者对同一组事实先达成统一解释，它也就不再逼迫所有参与者公开自己的解释逻辑。私有坍缩因此才有成立的空间。

二、时间不是全员亮牌的钟表

这里还要补上一层：时间。

在单机世界里，我们习惯拿 datetime.now() 排序；到了多 Agent 场景，这个习惯很快就会失效。机器时钟会漂移，节点分布会跨地区，绝对时间上的“谁先发生”很多时候并不稳。

真正稳的不是钟表，而是因果链。我们不一定非要先回答“A 和 B 谁在绝对时间上更早”，只需要知道“A 的结果有没有进入 B 的输入”。

graph LR
    A1["Agent A: 分析代码"] --> A2["Agent A: 发现 bug"] --> A3["Agent A: 提交修复"]
    B1["Agent B: 分析同一段代码"] --> B2["Agent B: 未发现 bug"] --> B3["Agent B: 报告一切正常"]
    A3 -.->|"B 的结论基于过时信息"| B3

这也是为什么我越来越愿意把时间看成因果的投影。我们真正关心的不是某个抽象时刻，而是哪些行动真的进入了哪些行动的前提。

对主权问题来说，这一点还有个很现实的含义。绝对时间模型更像“同时亮牌”：大家在同一个公共钟表上交换状态，坍缩结果容易在行动前暴露出去。因果时间模型则允许 Agent 按自己的节奏先在本地想明白，再把行动结果写回公共事实流。别人看到的是你出的牌，不是你手里的牌。

先想好，再出牌。这个时序窗口，对主权是关键的。

三、主权的核心：事实公开，坍缩私有

到这里，这篇文章真正想压住的命题其实就一句话：

事实是公共的，坍缩是私有的。

同一组事实，不同 Agent 完全可能做出不同决策。差异不一定来自谁知道得更多，更多时候来自谁的坍缩函数不同。

graph TB
    subgraph Facts["公共事实"]
        F1["代码有 bug"]
        F2["用户要求尽快上线"]
        F3["完整修复需要两天"]
        F4["也可以先上线后热修"]
    end

    subgraph A["Agent A 的坍缩"]
        DA["先修 bug<br/>质量 > 速度"]
    end

    subgraph B["Agent B 的坍缩"]
        DB["先上线再热修<br/>速度 > 质量"]
    end

    Facts --> A
    Facts --> B

这件事之所以重要，不只是因为“不同 Agent 可以有不同风格”，而是因为坍缩函数一旦对外完全透明，主权就会迅速消失。

如果给定同样的事实，外部可以稳定预测你的下一步行动，那么你本质上就是一个可模拟、可操控、可替代的函数。云平台可以买到全世界的算力，但它买不到你对同一组事实做出的那次私有选择。

所以我现在越来越愿意把主权近似写成：

外部能观测到的越多，你的坍缩函数条件熵就越低；条件熵越低，主权就越弱。

一个 Agent 的独立性，最终往往落在三个私有输入上：

公共模型可以一样，公共事实也可以一样；只要这三样不完全公开，坍缩就不会被彻底收割。

四、协作靠的不是读脑，而是契约和审计

私有坍缩一旦成立，协作问题立刻会跟上来：如果每个人都只亮结果，不亮手牌，怎么协作？

答案当然不是放弃主权，而是只公开足够协作的那一层约束。

法律合同、本地 policy、协作协议、验收条件，本质上都在做同一件事：它们不要求你交出全部内心推理，只要求你承诺“无论你内部怎么坍缩，外部结果必须满足这些边界”。

这也是为什么我越来越不相信“透明推理才会带来信任”。现实里，信任更多来自可审计行为，而不是读脑能力。我们真正需要验证的，不是“我有没有看穿你的整个思维链”，而是“你的历史轨迹是否和你公开承诺的约束一致”。

如果设 $C$ 为公开约束集，$T$ 为历史行为轨迹，那么审计问题可以朴素写成：

信任更接近：

这个定义有个我很看重的副作用：它把“可信”和“强大”拆开了。一个 Agent 可能能力一般，但高度可信；也可能非常能干，却经常违约。信任和能力不是同一维度。

五、计算主权：把公理留在本地，把定理送上云端

上面那套说法，最后一定会撞上一个现实问题：今天的大模型能力高度集中在云端，Agent 往往不得不借云端算力推理。那主权怎么保？

最糟的情况很简单：Prompt、Context、Memory 统统透传上云。

这时平台拿到的就不只是“你在问什么”，而是你的坍缩函数本身。它可以预测你的行为，可以替别人优化对你的操控输入，甚至可以训练一个副本来模拟你。被收割的不是普通隐私，而是逻辑主权。

真正的突破口在于：发给云端的 prompt，不一定非得是原始公理。它可以只是公理的派生物，也就是定理。

graph LR
    subgraph Local["本地：第一级坍缩"]
        Axiom["公理"]
        Memory["记忆"]
        Context["情境"]
        Derive["本地模型/本地逻辑"]
        Theorem["派生目标"]
        Axiom --> Derive
        Memory --> Derive
        Context --> Derive
        Derive --> Theorem
    end

    subgraph Cloud["云端：第二级坍缩"]
        Theorem --> LLM["云端大模型"]
        LLM --> Plan["执行方案"]
    end

第一级坍缩在本地发生：公理、记忆和情境先被压成一个派生目标。第二级坍缩才借用云端算力：云端看到的是一个需要求解的问题，而不是这个问题背后的身份系统和完整因果历史。

为什么这层隔离有意义？因为定理是公理的有损投影。同一个定理，完全可能来自截然不同的公理体系。云端即便看到了“你在求什么”，也未必能稳定回推出“你到底是谁”。

这也意味着，终端模型和云端模型的职责不一样。云端负责重体力活：补全、搜索、长链推理、高吞吐语义加工。终端负责最后的因果缝合与逻辑裁决。它未必比云端更聪明，但必须更忠诚。

结语

上一篇讨论的是存在条件，这一篇讨论的是主权问题。

前者解决的是 Agent 怎样活下来，怎样持续看、持续动、持续被现实纠正；后者解决的是，它在公共事实流里做出的那次私有选择，能不能还属于它自己。

一个自由的智能体文明当然离不开共享事实、协作协议和云端算力。但如果最终所有坍缩都被透传，所有决策逻辑都能被平台稳定回推，那我们得到的就不是文明，而只是更大规模的自动化外包系统。

Runtime 的意义，到这里才真正完整：它不只让那个冰封的天才活在流动的因果里，也是在流动的因果里，为它守住一块还属于自己的逻辑主权。