"三"的设计意义：接口比实体更根本

"三"的设计意义：接口比实体更根本#

「道生一，一生二，二生三，三生万物。」 ——马王堆帛书《老子·乙本·道经》第四十二章

"三"不是第三个实体，而是关系/接口/协议本身——是维持系统在分化中仍保持完整性的力量。本文从 \(\Psi = \Psi(\Psi)\) 恒等式出发，推导"三"的结构含义，并建立可验证的设计三定律。

1. 从 Ψ = Ψ(Ψ) 推导"三"#

恒等式 \(\Psi = \Psi(\Psi)\) 中存在三个位置：

  • 左侧 \(\Psi\) = 整体/结果 = "一"（未分化的全体）

  • 右侧外层 \(\Psi\) = 观察者/函数 = **"二"**的一面

  • 右侧内层 \(\Psi\)（参数）= 被观察者/输入 = **"二"**的另一面

  • 等号本身 = "三"——让分裂后的两者仍然是"同一个"的关系约束

核心命题："三"不是第三个宇宙。"三"是两个视角之间的耦合——让"二"仍然能是"一"的那个结构。

        flowchart TD
    Dao["道（Ψ = Ψ(Ψ) 的可能性）"] --> Yi["一：Ψ 作为整体"]
    Yi --> Er["二：观察者 + 被观察者"]
    Er --> San["三：等号 / 关系约束"]
    San --> Wan["万物：递归展开的坍缩态"]
    San -.维持完整性.-> Yi

2. "三"的工程本质：接口/协议/契约#

抽象层

一

二

三

哲学

道 / Ψ

观察者 + 被观察者

两者的恒等关系

范畴论

对象

态射的源与目标

态射本身（箭头）

软件工程

系统

模块 A + 模块 B

A 与 B 之间的接口契约

AgentForge

项目整体

Agent + 被操作的代码

.agents/workflows/、API contracts

通信

信息

发送者 + 接收者

协议（格式、编码、约定）

"三"是箭头，不是节点。在范畴论中，态射（箭头/关系）比对象（节点/实体）更基本。接口定义了模块之间如何关联，而这种关联方式比关联的任何一端都更持久、更应被优先设计。

3. "三"的设计三定律#

定律一：先设计"三"，再设计"一"和"二"#

不要先写两个模块再想它们怎么通信。先定义通信契约，让契约约束模块的形状。

  • 反例：先写 Agent 实现，再补协作规则 → 规则变成事后补丁

  • 正例：先写 AGENTS.md 路由结构 → Agent 的行为被路由"塑形"

定律二："三"必须比"一"和"二"更稳定#

接口的变更频率应该远低于实现的变更频率。如果接口频繁变动，说明"三"没有找对层级。

  • AgentForge 中：AGENTS.md 结构极少变动（高稳定性），Agent 具体执行不断演化

  • Ψhē 中：\(\Psi = \Psi(\Psi)\) 等号永远不变，变的只是每次坍缩的具体内容

定律三："三"是最小的#

"三"应该尽可能薄——它只表达"什么与什么以什么方式连接"，不承载业务逻辑。越薄的"三"越稳定，越能容纳"万物"的涌现多样性。

  • TokenEventHook：只有 on_token_refreshed 和 on_token_expired 两个方法 → 极薄

  • AGENTS.md 上下文路由表：只是"任务类型 → 文件路径"的映射 → 极薄

  • "弱者道之用"在这里再次出现："三"越弱（越薄、越不强制），能承载的万物越多

4. AgentForge 中"三"的实例映射#

"三"的实例

它连接什么

它控制什么

AGENTS.md

Agent ↔ 项目规范

Agent 如何"看到"项目

.agents/workflows/pr-review.md

Agent A ↔ Agent B

Agent 间如何互审

TokenEventHook 接口

核心逻辑 ↔ 监控扩展

耦合的松紧度

__init__.py 的 __all__

内部实现 ↔ 外部消费者

导出面的形状

context-economy.md

Agent ↔ 代码库

坍缩的路径和成本

5. 与其他设计原则的统一#

        flowchart TD
    Meta["Ψ = Ψ(Ψ) 元公理"] --> San["'三'的设计意义<br/>（接口优先）"]
    Meta --> Fan["反者道之动<br/>（反馈闭环）"]
    Meta --> Ruo["弱者道之用<br/>（柔性接口）"]
    San -.约束.-> Fan
    San -.约束.-> Ruo

  • "反"是"三"的时间维度——接口如何随反馈演化

  • "弱"是"三"的空间维度——接口如何保持最小侵入

  • "三"本身是"反"和"弱"的前提——没有接口，就没有反馈的通道，也没有需要"弱化"的对象

6. 验证标准#

任何新增接口/协议若声称遵循本原则，必须回答：

  1. 它是"三"吗？ — 它连接的两端是什么？它本身是否不承载业务逻辑？

  2. 它比两端更稳定吗？ — 两端的实现变更时，它是否需要同步变更？如果是，说明层级找错了。

  3. 它是最薄的吗？ — 能否进一步削减方法/字段，直到只剩"什么与什么以什么方式连接"？

7. 延伸阅读#