一个正在运转的多 agent 协作体系，哪些可以公开、哪些不能？本文介绍一种三层边界模型——不是简单的「开/关」二分，而是根据内容性质分层处置。
为什么不是简单的「开源」或「不开源」
「开源」这个词在软件世界里有很明确的含义：代码公开，谁都可以看、可以用、可以改。但当我们讨论的不是一段代码，而是一套正在运转的协作体系时，问题就变得复杂了。
这套体系里有方法论（怎么设计门禁、怎么衡量闭环），有机制代码（拦截逻辑、代理层、审计链），也有运营数据（谁在做什么任务、变更了什么内容、凭证在哪里）。把方法论公开是有益的——它可以被讨论、被改进、被其他团队借鉴。把运营数据公开是危险的——它会让攻击者知道体系在哪里、怎么绕。
简单的「全开」或「全关」都不合适。需要的是一个分层模型。
三层边界
第一层：概念层——完全公开
这一层包含的是方法论和设计理念：门禁式治理的思路、机器化率的定义、证据门槛的裁决逻辑、不变式的归纳方式。
这些内容不包含任何具体的规则编号、人名、阈值或内部拓扑。它们回答的是「为什么这样做」和「大框架是什么」，而不是「具体怎么配」。
公开这一层的价值在于：方法论可以被独立评估。别人不需要知道你的具体规则是什么，就可以判断「门禁式治理」这个思路是否合理、机器化率这个指标是否有意义。
第二层：机制代码层——部分公开，须脱敏
这一层包含的是实现逻辑：门禁拦截的代码骨架、代理层的协议翻译、收尾闸门的检查流程、审计链的数据结构、巡检的框架。
这些代码可以公开，但前提是脱敏——删掉所有私有常量、内部地址、具体规则编号之后，它仍然能独立跑起来（或者至少能让人理解机制是怎么工作的）。
脱敏不是简单地替换几个字符串。它需要遵循一套纪律（后文详述），确保脱敏后的代码不泄露任何私域信息。
第三层：私域层——绝不开源
这一层包含的是：具体规则正文、权限矩阵、任务派工单与账本、经验库、运营数据、凭证、内网拓扑。
这些内容一旦泄露就会造成实际损害——不是理论上的风险，而是立刻可以被利用的漏洞。比如，知道具体的权限矩阵，攻击者就可以构造恰好绕过拦截的请求；知道内网拓扑，就可以定向攻击单点。
这一层没有「部分公开」的余地。
脱敏四纪律
对于第二层（机制代码层）的公开件，必须满足四条脱敏纪律：
一、无真实身份名——不使用任何真实的 agent 名称或人名。用占位符替代（如 <agent-name>）。
二、无内网地址与端口——不出现任何内网 IP、域名或端口号。所有地址用占位符替代（如 <API_HOST>、<PORT>）。
三、无业务词——不出现客户名称、项目名称、账号标识等与具体业务相关的词汇。
四、无阈值——可以讲模式、讲机制，但不能把具体的阈值数字一起公开。因为阈值就是拦截的边界——知道阈值就知道怎么恰好绕过。
这四条纪律不是建议，而是硬约束。任何不满足这四条的公开件都不允许发布。
怎么判断一条内容属于哪一层
一个简单的判据：
如果删掉它不影响别人理解方法论 → 概念层，可以公开。
如果删掉它代码还能跑（或机制还能被理解） → 机制代码层，脱敏后可以公开。
如果它的泄露会立刻被利用 → 私域层，绝不开源。
实践中最难判断的是第二层和第三层的边界。比如「审计链的数据结构」——结构本身是机制（可以公开），但结构里的具体字段值（如某个 agent 的真实身份标识）是私域。
与其他开源策略的区别
常见的开源策略是二分的：要么全开（MIT/Apache），要么全关（proprietary）。这套三层模型的区别在于：它承认一个事实——一套运转中的体系，不同性质的内容需要不同的处置。
方法论公开有利于生态；机制代码脱敏公开有利于被审计；运营数据保密是安全底线。三者不矛盾。
这也意味着「开源」这个词在这里的含义比传统软件开源更精细——它不是「代码公开」那么简单，而是「在保护运转安全的前提下，尽可能多地公开可公开的部分」。
小结
三层边界模型的核心是：
概念层完全开——方法论可以被独立评估和改进。
机制层脱敏开——删掉私有信息后能独立理解或运行。
私域层绝不开——泄露即造成实际损害的内容没有商量余地。
配合脱敏四纪律（无身份名、无内网地址、无业务词、无阈值），确保公开件不会成为攻击入口。
这不是一个完美的模型——边界的判断需要人工审核，不能全自动。但它比简单的二分法更诚实地面对了现实：一套运转中的体系，不是所有东西都能公开，也不是所有东西都必须保密。