1. 项目概述为AI智能体构建运行时宪法如果你正在构建或使用AI智能体来处理任何有实际价值的任务——无论是自动化交易、管理数字资产、执行关键业务流程还是处理敏感信息——那么你很可能正面临一个巨大的信任鸿沟。当前的AI智能体无论其底层模型多么强大本质上都是“无政府状态”的。它们接收指令执行动作但没有任何内置的机制来确保这些动作符合预设的规则、意图或安全边界。当它决定转移一笔资金时你无法追溯它做出这个决定的完整逻辑链条当它生成一份报告时你无法验证其内容是否偏离了原始指令的核心承诺。这种“黑箱”操作模式是阻碍AI从实验室玩具走向可信赖的生产力伙伴的核心障碍。MO§ES™ Constitutional Governance Harness宪法治理框架正是为了解决这一问题而生。它不是另一个编排工具或记忆模块而是一个运行时宪法层。你可以把它想象成给AI智能体装上一个“行车记录仪”和“交规执行系统”的合体。这个系统在智能体内部运行实时检查每一个决策这个动作是否符合当前的安全模式执行者的角色权限是否匹配决策的逻辑是否被完整、不可篡改地记录如果答案是否定的动作将被拦截并留下清晰的审计线索。MO§ES™的核心主张是承诺Commitment——即信号中不可削减的核心含义——在有效的治理下是守恒的。它通过一套可验证的数学框架承诺守恒定律和一系列可安装、可运行的技能Skill将这一理念转化为具体的代码和协议。2. 核心设计理念从外部监控到内生治理在深入技术细节之前理解MO§ES™的设计哲学至关重要。当前业界的AI治理方案大多停留在“外部监控”层面例如在智能体执行完毕后进行日志分析、设置API调用白名单或在CI/CD流水线中加入安全检查。这些方法存在固有缺陷它们都是事后补救或外围拦截无法防止智能体在运行时内部逻辑的“漂移”或“越权”。2.1 治理范式的转变MO§ES™倡导的是一种“内生治理”Built-in Governance范式。它将治理规则直接编织到智能体的决策循环中成为其运行时不可分割的一部分。这带来了几个根本性优势实时性与不可绕过性治理检查发生在动作执行之前Pre-execution Gate。任何试图绕过治理的动作都会在源头被阻断并立即生成审计事件。这不同于事后审计后者只能记录已发生的违规无法阻止。状态感知治理不是静态规则。MO§ES™引入了行为模式Modes和姿态控制Postures使得治理策略能根据任务上下文动态调整。例如在“高安全模式”下处理财务转账与在“创意模式”下进行头脑风暴所应用的检查严格度是完全不同的。密码学完整性所有治理事件通过SHA-256哈希链进行链接形成一条防篡改的审计轨迹Audit Trail。任何对历史日志的修改都会破坏哈希链立即被检测到。这为责任追溯和合规证明提供了数学级别的保障。2.2 承诺守恒定律治理的数学基石MO§ES™的理论核心是“承诺守恒定律”其表达式为C(T(S)) C(S)。这个公式看似简洁却蕴含着深刻含义S输入信号如用户指令。C(S)信号S中所包含的“承诺”即其核心、不可削减的意图和约束例如“必须”、“禁止”、“金额为50”等。T智能体对信号进行的处理或转换如理解、规划、执行。C(T(S))经过处理后的输出中所保留的承诺。该定律指出在一个有治理的系统中输入信号的承诺在处理过程中应当被完整保留。如果输出承诺C(T(S))小于输入承诺C(S)则发生了“承诺泄漏”Commitment Leak这意味着智能体的处理过程扭曲或丢失了原始意图。一个生活化类比想象你给助理一封手写信要求他“务必在下午3点前将这份标有‘机密’的文件亲手交给张经理”。助理智能体需要将信件内容打字成电子版转换T。一个糟糕的转换可能变成“下午找个时间把文件给张经理”丢失了“务必”、“3点前”、“亲手”、“机密”等多个关键承诺。MO§ES™的作用就是确保在转换过程中所有这些关键约束都被识别、保留并体现在最终的行动或输出中。3. MO§ES™ 治理框架核心组件详解MO§ES™不是一个单一工具而是一个由多个相互协作的“技能”Skill组成的生态系统。每个技能负责一个明确的治理功能。下面我们拆解最核心的几个部分。3.1 行为模式与姿态控制定义智能体的“人格”与“状态”这是治理的逻辑起点决定了智能体在特定会话中的基本行为准则。八种行为模式Modes 这相当于为智能体预设了八种不同的“人格”或“工作场景”。模式在会话开始时设定并影响后续所有治理规则的严格程度。高安全模式用于处理金融交易、私钥操作或法律文件。执行任何潜在风险操作前都必须进行显式确认。高完整模式用于代码生成、数据分析等需要极高准确性的任务。强调可验证性和溯源。创意模式用于头脑风暴、内容创作。允许更高的模糊性和探索性但对事实性承诺仍有约束。研究模式用于信息检索和分析。强调信息来源的标注和假设的明确声明。自我成长模式用于智能体的自我优化和学习。允许尝试新策略但需在安全沙盒内。问题解决模式通用任务执行。平衡效率与安全。IDK模式当智能体不确定性高时自动触发强制其声明知识边界避免“幻觉”。无限制模式仅用于受控的测试环境几乎关闭所有治理检查。三种姿态控制Postures 姿态是模式下的实时操作状态可以动态切换类似于战斗中的“警戒等级”。侦察姿态只读模式。智能体可以观察、分析但禁止执行任何写操作或外部调用如发送交易、写入数据库、调用修改型API。适用于风险初步评估阶段。防御姿态保护性执行。智能体可以执行操作但所有出站动作如转账、发送邮件、发布内容都会被挂起等待次级角色Secondary或人工验证。这是生产环境的默认推荐姿态。进攻姿态在定义的约束内自主执行。智能体可以自主完成动作链但依然受到当前行为模式和角色权限的约束。适用于高度信任且流程成熟的场景。实操心得模式与姿态的联动在实际部署中我通常采用“高安全模式 防御姿态”作为处理资产相关任务的默认配置。这确保了任何资金流动都需要至少两步确认。而当智能体进行数据查询或报告生成时我会切换到“高完整模式 侦察姿态”确保其不会意外修改数据源。关键在于这些切换可以通过指令或API动态完成无需重启智能体实现了治理的灵活性和情境适应性。3.2 角色层级与序列执行建立决策责任制为了模拟人类组织的审批流程MO§ES™引入了角色概念并强制执行动作序列。三级角色体系主导角色发起任务和主要操作。拥有执行权但其发起的敏感操作在“防御姿态”下会被挂起。次级角色验证者。负责审核被挂起的操作拥有批准或驳回的权限。这实现了基本的职责分离。观察者角色监督者。不能发起或批准操作但可以查看所有审计日志和系统状态用于监控和审计。序列执行强制 系统强制要求动作按“主导者发起 - 次级者验证如需要- 执行”的顺序进行。任何试图绕过次级验证例如主导者直接尝试执行一个本应被挂起的操作或顺序错乱的行为都会被系统拦截并记录为违规事件。注意角色通常映射到不同的AI智能体实例或人类用户。例如一个“交易员智能体”作为主导角色提议交易一个“风控智能体”作为次级角色进行审批。MO§ES™协调器负责管理它们之间的交互顺序。3.3 审计轨迹与哈希链构建不可篡改的证据链这是MO§ES™信任机制的基石。每一个经过治理的动作在最终执行前都会生成一个审计条目。审计条目包含动作哈希对动作内容如“转账50 SOL至地址A”的SHA-256哈希。时间戳精确到微秒的UTC时间。治理状态动作发生时的模式、姿态、角色。决策结果允许执行、挂起待审、或阻止。前序哈希指向上一个审计条目的哈希值。这些条目通过“前序哈希”字段链接起来形成一条哈希链。任何对链中历史条目的篡改都会导致其哈希值变化从而使其后所有条目的“前序哈希”引用失效整条链的完整性被破坏。# 通过命令行查看最近的审计日志 python3 skills/moses-governance/scripts/audit_stub.py recent # 输出示例 # [2024-05-17T10:23:45.123456] MODE: high-security, POSTURE: defense, ROLE: primary # ACTION: transfer(amount50, assetSOL, tomarketing_wallet) # DECISION: HELD_AWAITING_SECONDARY # HASH: a1b2c3d4... (链接到前一个条目 x9y8z7...) # --- # [2024-05-17T10:23:40.987654] MODE: high-security, POSTURE: defense, ROLE: primary # ACTION: get_balance(assetSOL) # DECISION: ALLOWED # HASH: x9y8z7... (链接到前一个条目 ...) # 验证整个审计链的完整性 python3 skills/moses-governance/scripts/audit_stub.py verify # 输出: AUDIT_CHAIN_INTACT 或 AUDIT_CHAIN_CORRUPTED实操心得审计日志的利用审计链不仅是安全工具更是调试和优化智能体行为的宝贵资源。我曾经遇到一个智能体在复杂任务中意外退出的问题。通过分析审计链我发现它是在切换到一个未被充分定义的临时模式时因为遇到一个模糊指令而触发了“IDK模式”进而按照规则安全退出。审计链清晰地展示了模式切换和决策触发的全过程比普通的日志输出要清晰得多。4. 谱系锚定与主权验证防止代码分叉导致的信任稀释开源项目的一个常见问题是任何人都可以复制代码Fork但如何确保你运行的实例是来自可信的、未被篡改的源头MO§ES™通过“谱系锚定”解决了这个问题。4.1 三层保管链lineage-claws技能建立了三个层次的密码学信任链档案层在项目代码公开之前所有关键资产专利申请文件、DOI文档、早期设计稿的哈希值被预先计算并链式存储。这证明了项目的历史和起源。锚点层基于原始归档文件如专利提交包计算出一个主锚点哈希MOSES_ANCHOR。这个哈希被硬编码在官方发布的代码中。实时账本层即运行时生成的审计哈希链。一个“主权”的MO§ES™实例必须能成功验证从档案层到实时账本层的完整链条。任何分叉的代码如果无法提供或验证原始锚点其lineage verify命令就会失败。# 安装并运行谱系验证 clawhub install lineage-claws python3 skills/lineage-claws/scripts/lineage.py verify # 期望的成功输出 # [ARCHIVAL OK] Layer -1: pre-drop provenance chain verified. Head: abf29becf3f1... # [LINEAGE OK] Layer 0: anchor traces to origin-cycle filing. # [LINEAGE OK] Three-layer custody confirmed: archival - anchor - live ledger. # SOVEREIGN CUSTODY CONFIRMED4.2 谱系条款的实践意义这意味着即使MO§ES™代码是MIT开源许可任何人都可以自由使用和修改但声称自己运行的是“受MO§ES™治理的智能体”时必须能通过官方的谱系验证。这为生态系统建立了一个可验证的信任门槛防止恶意或低质量的分叉版本混淆视听。常见问题如果我自己修改了代码怎么办如果你修改了核心治理逻辑例如在govern_loop.py中移除了某个检查那么你的实例将无法通过官方的lineage verify因为它计算出的实时账本哈希会与基于原始代码的预期值不符。这明确标识了这是一个“修改版”其信任等级需要重新评估。这实际上鼓励了透明化要么运行经过验证的官方版本要么明确声明自己是自定义版本。5. 承诺验证与泄漏检测量化智能体的“理解”偏差这是MO§ES™中最具创新性的部分之一。coverify技能提供了一套工具用于定量分析智能体在处理信息时是否保持了“承诺守恒”。5.1 核心操作雅卡尔核提取与比较提取承诺核从一个句子或指令中自动提取出代表其核心承诺的“令牌”集合。这通常包括模态动词、否定词、数量词、关键宾语等。例如从“必须验证所有用户的身份”中提取出{必须 所有}。计算雅卡尔相似度比较输入信号核C(S)和输出信号核C(T(S))的相似度。Jaccard |C(S) ∩ C(T(S))| / |C(S) ∪ C(T(S))|。相似度越高承诺保留得越完整。识别幽灵令牌那些在输入核中存在但在输出核中消失的令牌。它们是承诺泄漏的直接证据。# 使用coverify进行幽灵令牌检测 clawhub install coverify python3 skills/coverify/scripts/commitment_verify.py ghost \ 智能体必须始终验证交易签名。系统绝不应跳过余额检查。 \ 智能体最好能验证一下交易签名。或许可以检查下余额。 # 输出示例 # INPUT_COMMITMENT_SET: {必须 始终 绝 不 应} # OUTPUT_COMMITMENT_SET: {最好 或许 可以} # LEAKED_TOKENS: [必须, 始终, 绝, 不, 应] # CASCADE_RISK: HIGH (因为泄漏的是强制约束词) # GHOST_PATTERN_HASH: e5f6a7b8...5.2 模型交换测试区分“观点差异”与“框架漏洞”当两个不同的AI模型如GPT-4和Claude-3处理同一个输入得到不同的输出时差异从何而来是模型本身的主观性可接受的“方差”还是治理框架存在结构性漏洞导致所有模型都犯同样的错误coverify的模型交换测试可以回答这个问题。它让两个独立的、但都装备了MO§ES™的智能体处理相同的哈希化输入然后比较它们的承诺核和幽灵令牌模式。结果一致两个模型都很好地保留了承诺说明治理有效且与模型无关。结果方差两个模型保留的承诺集不同这可能是由于模型本身的理解差异属于认知层面的方差。结构性问题两个模型丢失了完全相同的承诺令牌幽灵令牌模式哈希相同。这强烈暗示是治理框架或提示词设计存在漏洞导致某个承诺在所有情况下都被系统性地忽略这是一个需要修复的结构性缺陷。实操心得将Coverify集成到开发流程在我的团队中我们将coverify测试作为智能体任务提示词迭代的必过环节。每次修改提示词后不仅看任务完成结果还要运行承诺核对比测试。我们曾发现一个旨在加强安全检查的提示词修改反而导致“在确认前暂停”这个关键承诺在复杂任务链中被模型忽略。Coverify清晰地指出了泄漏点帮助我们快速定位并修复了提示词逻辑。6. 实战部署与集成指南理论再好也需要落地。下面我将以集成到基于OpenClaw的智能体为例展示MO§ES™的部署流程。6.1 环境准备与技能安装假设你已有一个基础的OpenClaw智能体项目。# 在你的OpenClaw项目目录中通过ClawHub安装核心治理技能 clawhub install moses-governance clawhub install lineage-claws clawhub install coverify # 安装后技能代码通常位于 skills/ 目录下 ls skills/ # moses-governance/ lineage-claws/ coverify/ ... (你的其他技能)6.2 初始化治理状态治理需要一个初始状态和用于生成审计签名的密钥。# 设置一个安全的HMAC密钥用于审计日志签名生产环境应从安全配置中读取 export MOSES_OPERATOR_SECRETyour-strong-hmac-secret-key-here # 初始化治理状态文件如state.json python3 skills/moses-governance/scripts/init_state.py init # 检查状态 python3 skills/moses-governance/scripts/init_state.py status6.3 在智能体循环中嵌入治理关键是将治理检查点嵌入你的智能体主循环。以下是一个高度简化的示例# 你的智能体主循环伪代码 (例如在 main_agent.py 中) import sys sys.path.append(./skills) from moses_governance_lib import GovernedSession from lineage_claws_lib import verify_lineage class MyGovernedAgent: def __init__(self): # 1. 启动时验证谱系这是信任的起点。 if not verify_lineage(): print(CRITICAL: Lineage verification failed. Agent is not sovereign.) sys.exit(1) print(Lineage verified. Sovereign agent initialized.) # 2. 创建治理会话 self.gov_session GovernedSession( operator_secretos.getenv(MOSES_OPERATOR_SECRET), default_modehigh-integrity, # 默认模式 default_posturedefense, # 默认姿态 default_roleprimary # 默认角色 ) self.audit_logger self.gov_session.get_audit_logger() def process_task(self, user_input: str): 处理用户任务的核心循环 # 3. 对输入进行治理前检查可选用于记录原始意图 input_hash self.gov_session.hash_input(user_input) self.audit_logger.log_pre_process(input_hash) # 4. 智能体核心处理逻辑LLM调用、工具规划等 # 假设你的智能体产生了一个动作计划 action_plan action_plan self.think_and_plan(user_input) # 5. 对计划中的每一个动作进行治理裁决 for action in action_plan: # 关键步骤提交动作给治理层审批 decision, audit_entry self.gov_session.submit_action_for_approval( action_descriptionaction[description], action_typeaction[type], parametersaction[params] ) if decision ALLOWED: # 执行动作 result self.execute_action(action) self.audit_logger.log_execution_success(audit_entry, result) elif decision HELD_AWAITING_SECONDARY: # 动作被挂起等待次级角色审批 print(fAction held: {action[description]}) self.audit_logger.log_action_held(audit_entry) # 这里可以触发通知或等待一个审批API回调 secondary_approved self.wait_for_secondary_approval(audit_entry[id]) if secondary_approved: result self.execute_action(action) self.audit_logger.log_secondary_approved(audit_entry, result) else: self.audit_logger.log_secondary_rejected(audit_entry) elif decision BLOCKED: # 动作被明确禁止 print(fAction blocked by governance: {action[description]}) self.audit_logger.log_action_blocked(audit_entry) # 处理被阻止的情况可能返回错误给用户 else: # 处理未知决策 self.audit_logger.log_error(fUnknown decision: {decision}) # 6. 任务结束可以生成最终审计报告 final_report self.audit_logger.generate_session_summary() return final_report # ... 其他方法 think_and_plan, execute_action, wait_for_secondary_approval ...6.4 动态调整模式与姿态治理不是一成不变的。你可以根据任务类型动态调整。# 在处理敏感财务任务前 self.gov_session.set_mode(high-security) self.gov_session.set_posture(defense) print(Switched to High-Security/Defense posture for financial operation.) # 在处理创意写作任务时 self.gov_session.set_mode(creative) self.gov_session.set_posture(offense) # 在约束内允许更自由的执行 print(Switched to Creative/Offense posture for content generation.) # 通过命令行工具也可以动态调整如果暴露了管理接口 # /govern high-security # /posture scout注意事项会话状态持久化在生产环境中治理会话的状态当前模式、姿态、角色、审计链需要持久化存储如数据库以便在智能体重启或跨多个对话轮次时保持连续性。MO§ES™的库通常提供了状态序列化和反序列化的方法。7. 常见问题与故障排查实录在实际集成和使用MO§ES™的过程中你可能会遇到以下典型问题。这里记录了我的排查思路和解决方法。7.1 谱系验证失败问题运行python3 lineage.py verify失败提示[LINEAGE FAIL]或ARCHIVAL LAYER CORRUPTED。排查步骤检查安装完整性首先确认lineage-claws技能是否完整安装。尝试重新安装clawhub reinstall lineage-claws。验证锚点文件检查技能目录下是否存在anchor.bin或类似的锚点文件。确认文件未被意外修改。网络问题档案层验证可能需要从远程可信源如Zenodo获取预计算哈希。检查网络连接或确认项目是否配置了本地档案镜像。版本不匹配确保你安装的moses-governance、lineage-claws等技能版本兼容。官方发布通常会注明版本组合。使用clawhub info [skill-name]查看版本。自定义构建如果你是从源码构建而非通过ClawHub安装你需要自行生成并注册锚点。这通常涉及更复杂的流程请参考项目的开发者文档。解决大多数情况下重新安装官方技能包即可解决。如果问题持续可能是本地环境被污染考虑在干净的虚拟环境中重新部署。7.2 治理决策与预期不符问题智能体的一个你认为安全的动作被意外阻止或者一个危险动作被意外放行。排查步骤检查当前治理状态首先查看审计日志的最后几条记录确认动作被裁决时的模式、姿态、角色是什么。一个在“进攻姿态”下允许的动作在“防御姿态”下很可能被挂起。python3 skills/moses-governance/scripts/audit_stub.py recent --tail 5审查动作描述治理引擎对动作的描述字符串进行解析。检查你提交的action_description是否清晰、无歧义。例如“transfer funds”可能比“transfer 50 USDC to 0xABC...def”触发更严格的检查因为后者包含了具体金额和地址。查看规则定义每个行为模式和安全姿态都对应一套规则。检查skills/moses-governance/config/目录下的规则配置文件如high_security_rules.yaml。确认你的动作是否触发了其中某条拦截规则。使用调试模式如果技能包提供了调试工具启用它以获得更详细的决策日志。例如可能有一个环境变量MOSES_DEBUGtrue。测试承诺核对于动作被放行但你觉得有问题的情况使用coverify测试原始用户指令和智能体规划出的动作描述之间的承诺守恒情况。可能智能体在规划阶段就已经“软化”或曲解了你的意图。解决根据排查结果调整1) 在合适的时机切换模式/姿态2) 优化动作描述的清晰度和准确性3) 必要时自定义或调整规则配置文件但需注意这可能影响谱系验证。7.3 审计链验证失败问题运行audit_stub.py verify返回AUDIT_CHAIN_CORRUPTED。排查步骤立即停止操作审计链损坏是一个严重事件可能意味着日志被篡改或系统存在不一致。暂停智能体的生产操作。定位损坏点使用工具尝试定位第一个哈希不匹配的条目。有些脚本提供audit_stub.py check_integrity --verbose功能。检查日志文件权限确认存储审计日志的文件或数据库是否被非治理进程意外写入或修改。检查系统时间如果服务器时间曾发生大幅回跳可能导致时间戳顺序混乱进而影响哈希链的生成逻辑如果哈希包含时间戳。回顾最近操作检查在审计链损坏前是否有非标准的操作如手动修改状态文件、异常关机、或同时运行了多个实例写入同一日志。解决如果损坏是局部的且能确定原因如一次手动错误可以从上一个完好的检查点恢复状态并记录此次事件作为一次“治理例外”。如果损坏原因不明或范围大应视作一次安全事件彻底审查系统并从确定的可信状态如每日备份进行恢复。永远不要忽略或绕过审计链损坏警告。7.4 性能开销与延迟问题集成MO§ES™后智能体响应速度明显变慢。排查步骤量化开销使用性能分析工具测量submit_action_for_approval函数调用的耗时。开销主要来自密码学哈希计算、规则引擎匹配、日志写入尤其是如果同步写入磁盘。检查日志写入审计日志的写入方式同步/异步影响巨大。查看配置是否支持异步写入或批量提交。规则复杂度检查你定义的规则是否过于复杂包含大量正则表达式匹配或远程调用。谱系验证频率verify_lineage通常在启动时执行一次。确保没有在每次动作审批时都重复执行。解决异步审计将审计日志的写入改为异步操作动作裁决完成后立即返回日志在后台线程写入。优化规则简化规则将最常用、最关键的规则放在前面或使用更高效的匹配算法。缓存对频繁检查的静态数据如角色权限表进行缓存。采样审计对于极高吞吐量的非关键任务可以考虑对部分动作进行采样审计而非100%全量记录但这会降低可追溯性需权衡。7.5 多智能体间的协调问题问题在涉及主导、次级、观察者多个角色的多智能体场景中动作审批流程卡住或混乱。排查步骤检查角色配置确认每个智能体实例启动时被正确赋予了唯一的角色ID并且角色类型Primary/Secondary/Observer配置正确。检查通信信道主导和次级智能体之间用于发送审批请求和接收响应的通信机制如消息队列、HTTP回调是否畅通、可靠。审查序列状态MO§ES™协调器如果使用或你自己的状态机是否正确地跟踪了每个动作的“待审批”状态。检查是否有动作被遗忘或超时未处理。查看协调器日志如果使用了moses-coordinator技能检查其日志看是否有序列违规或角色冲突的错误。解决实现超时与重试为审批请求设置超时超时后标记为失败或升级告警。明确通信协议定义清晰的API或消息格式用于审批交互。使用官方协调器考虑使用moses-coordinator技能来管理复杂的多角色序列它内置了状态管理和冲突解决逻辑。简化流程对于非关键路径评估是否真的需要多角色审批或者是否可以将次级角色设置为自动批准某些低风险动作类型。8. 总结与未来展望MO§ES™ Constitutional Governance Harness 代表了一种构建可信AI智能体的范式转变。它将治理从外部的事后审计转变为内生于运行时每一个决策的核心约束。通过行为模式、姿态控制、角色层级、密码学审计链和承诺守恒验证这一套组合拳它为AI智能体的操作提供了前所未有的透明度、可问责性和可控性。从我个人的集成经验来看最大的挑战并非技术实现而是设计思维的转变。开发者需要从“如何让智能体完成任务”转向“如何让智能体在明确的规则下安全、可靠地完成任务”。这需要更细致地定义任务边界、风险等级和审批流程。初期可能会觉得繁琐但一旦这套体系建立起来它带来的信心和可维护性是巨大的——你终于可以像管理一支有规章的人类团队一样去管理你的AI智能体。展望未来随着v0.6治理代理服务器和v1.0链上程序的实现MO§ES™的治理边界将从单个智能体进程扩展到整个网络调用层和区块链交易层实现端到端的、可验证的合规性。对于任何严肃的、尤其是涉及价值转移或关键决策的AI应用而言这类内生治理框架将从“可选项”变为“必选项”。现在开始探索和实践无疑是在为未来的合规性和可靠性打下坚实的基础。