Bab 25 — Arsitektur Teknis Menyeluruh untuk Tata Kelola Modal Pemangku Kepentingan

第二十五章　利益相关者资本治理的整体技术架构

前五篇分别讨论了制度技术、数字资产、共识执行、贡献确认、资本与权益，以及多方治理。进入系统构建时，需要把这些论证放进同一张能够运行的关系图：共同创造怎样形成业务事件，哪些证据支持对事件的确认，哪一版规则决定后续处理，谁因此获得何种请求，最后又由谁监督结果并修订规则。

上一章把视角扩展至跨组织协作。不同企业可以共用部分记录和核验程序，但仍保有各自的权利义务与现有系统。这使架构设计不能从“把一切放到链上”出发，而应从制度所需的共同状态、事实来源、责任主体和实际履行出发。区块链在其中承担被明确选择的职能，其余工作需要业务流程、数据服务和组织程序共同完成。

本章提出的是一种可检验的整体架构，不是要求所有企业采用同一套产品。判断架构是否有效，应看它能否支持明确的业务闭环、保留权利边界、处理错误与争议，并在需要时替换某项技术而不使参与者失去已形成的请求。

一、业务、证据、规则、权益与治理模块

整体架构可以按五类职责组织。业务模块说明共同创造正在做什么，证据模块保存何以认定相关事实，规则模块确定这些事实如何进入制度判断，权益模块表达由此成立的具体权利和履行状态，治理模块决定、监督和修订这些安排。模块是职责边界，可以由不同软件承担，也可以部署在同一系统中；分开的目的，是让每一步有可核验的输入和有权负责的人。

业务模块应从承诺和任务开始。它记录合作对象、任务范围、交付要求、期间及参与角色，并在工作推进中接收投入、交付、采用和结果信息。企业原有的项目、订单或服务系统可以继续承担大量业务处理；共同架构只需取得完成后续确认所必需的事件和标识，不必另造一套覆盖全部经营活动的界面。

任务与事件需要保持关系。一个交付可能回应多个承诺，数个组织也可能共同完成一个成果；修改、撤回或追加交付时，应能找到原任务与原参与者。业务模块输出的是待核验的事实主张，不应因字段填满便直接输出“贡献价值”或“应得权益”。

证据模块关注来源与证明范围。谁提交了材料，谁签收或核验，材料证明交付、质量还是使用结果，是否存在异议，以及原始资料由谁保管，都应在此得到表达。对不同可信度的材料可以采用不同核验路径，但证据之间的冲突不能靠覆盖旧文件处理。保留原始状态、修订原因和有权复核的结果，是后续审计的基础。

规则模块把有效制度与可执行条件连接。它保存资格、计量、转换、分配和审批规则的版本及适用范围，并指向形成规则的授权决定。纯粹的计算逻辑可以由程序运行，依赖事实评价或例外裁量的事项则应进入相应人工程序。规则模块要能够回答“为什么在这个期间、对这个主体适用这一版规则”，不能只返回一个缺乏依据的数值。

权益模块不能被简化为通证余额。它应区分贡献账户、资本记录和权益账户，并在权益内部说明所有权、收益请求、治理参与、使用资格等不同安排。每项具体权益要连接主体、义务主体、成立依据、限制和兑现条件；若采用数字凭证或通证，还需说明凭证状态与权利变动如何对应。凭证转移不应悄然改写历史贡献或企业已有义务。

权益模块还需跟踪履行过程。已确认资格、已计算金额、已成立请求、已安排支付、链上转移成功和链下实际收款，不能只有一个“完成”标记。若支付被退回、权益遭到争议或部分履行，系统要能保留原请求与后续处理的联系，使余额具有清楚的现实含义。

治理模块负责提案、审议、授权、监督和救济。它管理参与资格、代表与委托关系、表决程序、利益冲突披露，以及规则变更的生效状态。它也接收业务和权益环节中的异常，决定哪些问题可按现行规则纠正，哪些需要重新审议制度。治理模块的输出不是一串抽象投票数据，而是对确定事项有效的决定与相应执行责任。

五个模块之间还需要共同的基础能力：身份与代理关系管理、时间和版本标识、事件关联、访问控制、审计日志及通知。基础能力不应变成新的不受约束的权力中心。例如，负责维护身份服务的人可以帮助核验代理权限，却不能因此决定该代理人有权代表企业批准额外的收益分配。

从一条具体流程看，业务事件先进入证据核验；得到确认的事件按适用规则计算；经过必要的人工作出资本或权益判断；权益结果再进入履行与对账；异常、异议和效果评估返回治理程序。这条流程并非每一步都必须发生：已确认的贡献可能没有资本化条件，资本形成也可能没有为该贡献者设立新的所有权。系统应允许流程止步，并解释止步的依据。

流程还应能逆向追踪。审计者从一笔权益或支付，能够查回原业务、证据、规则、授权和实际付款；当某项证据被撤销，系统则能找到受其影响的评价、请求与支付。设计阶段若只关注顺向发放，不考虑逆向查找，后续纠错就可能必须依赖人工逐页搜寻。

模块化的最终目的不是画出整齐的系统图，而是阻止概念在接口处被悄然合并。投入不自动成为贡献，贡献不自动成为资本，资本不自动成为所有权，收益权也不自动赋予治理权。每一次跨越这些边界，都需要对应的制度条件、事实依据和有权程序。

二、链上链下的数据与执行分工

把哪些信息写入链上，首先应看参与者是否需要共同确认同一状态、对单方修改是否存在实质争议，以及维护分布式核验是否具有足够价值。数据规模、敏感性、更新频率和删除需求也会影响选择。共享账本、签名日志或普通数据库各有作用，不宜以“重要数据一律上链”代替逐项判断。

链上更适合保存多方共同需要核验的状态转换：某项授权是否已经满足，某笔数字资产控制是否转移，某个规则版本何时被共同采用，以及某次更正与原记录如何关联。在具体设计下，也可以保存可验证的凭证状态或证据摘要。链上存储的位置并不决定权利是否成立；若对象是现实资产或服务，仍须检查链下关系与履行。

链下通常保存容量较大、需要频繁修改或受访问限制的业务资料，包括合同、交付文件、人员信息、财务细目、质量报告和争议材料。链下并不意味着无法审计。资料可以保留来源、版本、签名与必要摘要，通过受控查验与链上记录相互印证。若原始文件已经遗失，链上的摘要只能证明某个文件曾被对应记录，无法替代丢失的内容。

执行也需要分工。条件明确且输入可靠的状态转换，可以由智能合约或其他规则引擎自动处理；事实核验、例外裁量、现实资产交付和跨机构支付，则需要相应业务与组织程序。链上交易执行成功，只能证明在该协议条件下完成了对应动作，不能统一解释为链下服务已经提供或义务已经清偿。

数据进入链上前，最重要的是输入责任。谁可以提交业务结果，谁复核材料，提交者的签名证明什么，以及发现错误后怎样标注和更正，应比选择哪一种预言机或接口更早确定。只把错误资料以更可靠的方式保存，会增加错误长期存在的影响范围。

链上链下连接还要处理不同的时间。交付完成、审核确认、链上记录被确认、付款发起与现实到账，可能发生在不同日期。系统应保留各自时间与状态，避免因链上确认较早就把付款显示为已到达，或因业务系统尚未更新而重复生成相同权益。

敏感信息不宜为了透明而公开复制。对个人身份、薪酬、商业秘密和未公开争议，可以只开放必要的资格证明、总量核验或经过授权的审计查询。W3C 的可验证凭证数据模型提供发行者、持有者与核验者之间交换陈述的结构，并讨论凭证状态和数据最小化；这种结构可以服务于某些跨系统证明，但能否相信陈述内容仍取决于发行者和实际证据。W3C：可验证凭证数据模型 2.0〔1〕

跨系统操作可能出现一边成功、一边失败。链上已锁定额度，银行支付却被退回；链下服务已交付，链上凭证却尚未生成。架构应提供稳定的业务请求标识、可重试的操作记录和差异处理队列，使各方知道哪一步完成、哪一步待查。不能因为跨系统无法像单一数据库事务那样同时完成，就把某一边强行改写为已经发生的结果。

选择链上范围还需要考虑长期成本与治理。网络费、读取方式、合约升级权限、历史数据保留和节点运营，都影响参与者未来能否核验自己的请求。某一时期成本低，不保证长期适用；若网络或运营方发生变化，制度仍应能解释存续的权利、取得必要证据，并安排迁移或替代履行。

因此，链上链下的分工应接受一项朴素检验：将某项数据或操作移到链上后，究竟改善了什么共同问题，谁承担新增成本，以及何种事实和权利判断仍需链下完成。只有答案清楚，共享账本才成为制度技术的一部分，而不是给旧流程增加一层难以解释的记录。

三、与财务、人事、客户及供应链系统的连接

利益相关者资本治理并不是企业经营数据的唯一来源。财务系统维护收入、成本、应付和实际收付；人事系统管理劳动关系与岗位变更；客户系统保存使用、反馈及服务记录；供应链系统追踪订单、交付、验收与退回。治理架构应从这些既有系统获取经授权、可核验的信息，再按自身制度生成相应结果。另建一份互不对账的“治理数据”，只会增加冲突。

连接前应识别每类事实的权威来源。财务部门确认某笔款项已到账，不等于它确认了某参与者符合收益分配条件；人事部门确认某人曾任职，不等于它确认此人在某项目上的贡献分值。一个系统可以对部分事实具有记录优势，但不能因其被称为“主系统”，就获得对所有制度判断的最终解释权。

财务连接应围绕资源与义务建立映射。本书前面区分了收入、利润、现金流和可分配资源，架构也应保留这些分类。分配模块从财务系统取得经过适当核验的核算结果和资源状态，形成候选分配范围；有权主体作出方案决定后，支付指令再回到实际支付路径，并将回执与原请求逐项对账。治理系统不能用自己展示的通证价格或账户余额替代组织的真实履行资源。

财务系统还需接收治理侧的有效请求。权益成立后，是否构成应付、何时结算、金额怎样调整，应由有关制度和适用核算要求共同确定。系统接口应传递请求来源、期间、义务主体和更正记录，避免把一项尚待条件满足的奖励显示为已经到期的货币支付，也避免支付已发生却未更新权益状态。

人事连接的重点是身份、角色与代理关系。员工入职、调岗、休假和离职可能改变参加未来任务或代表企业操作的资格，但对过去已经确认的贡献和已经成立的请求，不能由人事状态变更自动抹除。治理系统应区分“当前有权执行某项操作”与“历史上是谁完成了工作”，并给离岗人员保留适当的结算与异议渠道。

客户系统可以提供使用、服务和反馈证据，却不应将点击、停留或购买次数直接换算成资本。某项客户反馈是否构成有效贡献，需要事前说明任务目标、证据质量与使用结果。客户资料还有明确的访问目的和保密边界；将行为明细全部复制到共享账本，只会扩大与评价无关的信息暴露。

供应链系统连接更强调多方确认。订单发出、货物送达、质量验收、安装使用和售后退回，代表不同状态。供应商提交的发货记录可以与采购方的签收、检验记录互证，但一方“已发货”不能自动改成双方“已完成履约”。若出现部分交付或退货，贡献评价和结算安排都要能找到原事件并保留调整依据。

这些系统之间通常采用不同编号和时间口径。一个人可能在项目系统有参与者编号，在人事系统有员工编号，在支付系统有收款对象编号；同一订单也可能拆成多个交付与付款批次。连接层需要维护受控的对应关系，并记录每个编号的来源与有效期间。跨系统统一身份，不等于公开暴露所有内部标识。

接口接收事件时，应区分新增、更正与撤销。财务冲回、人员身份纠错、客户撤回错误反馈或采购退货，都可能改变已有计算。连接层应把变化送入有权复核的流程，标出受影响的下游权益；不能静默覆盖原始事件，也不能机械地把每次更新当作一份新的贡献。

重复消息和迟到消息也需要处理。同一来源系统可能重发交付事件，网络中断后旧消息又可能晚于新状态到达。稳定的业务标识、来源版本、事件时间与接收时间，可以帮助系统识别重复和先后关系。技术上阻止重复导入只是第一步；若业务本身确有两次相似交付，还需要回到任务和证据判断其是否属于不同事件。

连接责任应落到接口两侧。来源部门负责什么数据质量，治理系统负责什么规则解释，技术服务商负责什么传输与运行，都应清楚。发现差异时，应能说明谁核对原始记录、谁决定是否重算、谁通知受影响者。接口越自动化，越需要避免“系统之间传过去了，所以没有人负责”的空白。

架构也要允许企业现有系统暂时不具备标准接口。起步时可以采用有权限、有版本和有复核的批量导入，只要来源和校验条件清楚，仍可以建立可审计的流程。是否进一步实时连接，应根据业务变化速度、错误成本和实施资源判断，而不是把系统集成程度直接当作治理质量。

四、数据标准、接口边界与系统可替换性

要让不同模块和组织长期协作，首先需要共同理解数据。主体、角色、任务、贡献事件、证据、规则版本、资本记录、权益请求、履行结果和异议，至少应各有明确定义。数据标准不只是字段格式，还包括一项状态何时产生、由谁确认、可在哪些场景使用，以及何种变化必须产生新记录。

“已确认”尤其不能成为跨模块的模糊通行证。业务已验收、贡献已确认、资本已形成、权益已成立和支付已完成，分别指向不同对象。标准应要求记录写明所确认的内容、依据、权限、时间和版本；任何模块引用它时，还要说明该确认是否足以支持当前动作。

共同标识使跨系统记录能连接，但标识策略应考虑合并和分离。两条记录后来被证实属于同一主体，或一个组织发生业务拆分，都不能只靠删除其中一个编号解决。系统应保留映射的依据和有效期间，使历史请求仍可追溯。标识符本身也不应被当成对现实身份或代理关系的充分证明。

接口边界需要写成双方可以检验的约定。接口提供什么事实，接收方有权怎样使用，哪些字段为必填，错误如何返回，多久可以取得更正，以及旧版本停止支持前如何通知，都应有明确规则。对于会产生经济请求的接口，还要注明重复处理、超时和重试后的核对办法，不能让传输成功自动代表制度判断成功。

数据标准与组织规则需要同步管理。增加一项“贡献类型”看似只是扩充选项，却可能改变评价口径；调整“已履行”的定义可能影响应付与对账。对数据含义的变更应有相应制度授权，并明确新旧数据如何比较。否则，程序仍能运行，结果却可能已经失去可解释性。

可验证凭证、签名日志或共享账本可以为部分记录提供一致的交换与核验形式。标准形式仍须配合可信发行者、业务定义和接收方的判断。技术互通解决的是机器能否识别一份声明；制度互通还需要各方同意它在何种范围内具有作用。因此，选择标准时要同时检查规范是否清楚、各方是否能实现，以及退出后是否仍能核验历史声明。

系统可替换性应落实到具体对象。更换证据存储，不应丢失原始文件与版本关系；更换规则引擎，不应改变已生效规则对旧期间的适用；更换钱包或账本服务，不应让已成立请求失去主体对应；更换平台运营者，不应使监督者无法读取必要审计材料。没有这些验证，所谓模块化只是部署图上的分隔。

替换需要可导出的资料、可读的规则、可核验的历史以及可执行的交接。导出不仅是下载一份表格，还应说明字段含义、记录之间的关系、签名或摘要怎样验证、未完成事项处于什么状态，以及由谁继续履行。涉及其他主体的材料，还要按权限和保密条件处理，不能为了可迁移性任意扩大数据复制。

接口替换也需要兼容期。新旧系统可以在限定时间内并行核算，对相同业务给出结果并解释差异；正式切换则应明确截止时点、未完成请求的处理者和回退条件。若并行过程中发生实际支付，必须指定唯一的执行路径，以免两套系统分别把同一请求当作待付。技术切换不应变成权利内容的隐蔽修订。

为了验证架构是否真正可以替换，可以定期选取有代表性的任务，从业务事件重建证据、规则、权益和履行结果，并在备用系统中复算。差异应能解释，而不是靠修改备用数据消失。这种演练也能暴露对某个供应商、某把密钥或某个没有文档的内部判断的依赖。

架构治理还要为接口留有更正和申诉入口。自动导入会提高处理量，也会放大来源错误；模块一旦互相引用，错误可能快速进入贡献评价、权益和支付。系统应能把有疑问的输入隔离出来、查找受影响结果、在有权程序下重算，并为已履行部分提供后续处理路径。可替换性与可纠错性在这里相遇：两者都依赖清楚的来源和版本。

本书提出的整体架构，可以从一个范围有限的闭环开始验证：明确参与角色和一项共同任务，保存必要证据，应用已授权规则，形成可解释的权益结果，核对实际经营与履行，再将异常和反馈带回治理。这样的起点能检验模块之间是否真的连接，也能让组织看清哪些工作需要继续人工判断，哪些共享状态值得采用区块链。

技术架构最终要服务于共同创造持续形成的资源、能力与合作关系，而不是以模块数量或上链比例证明成功。只有业务、证据、规则、权益和治理之间的责任能够被理解、核验并延续，制度技术才可能成为利益相关者资本治理的基础设施。

下一章将进一步讨论安全、隐私与系统持续运行，检验这套架构在合约缺陷、密钥风险、错误输入、数据保存及灾难恢复面前，能否继续维护参与者的权利和组织的行动能力。

定稿补强：三类可用性与财务接口控制

整体架构应把协议数据可用性、证据可取回性和业务连续性配置到不同责任模块。链上状态层负责可验证的共同状态，证据层负责在权限和保留期内提供材料，业务系统负责持续履行与恢复。接口必须标明权威来源、版本、失败模式和降级路径。

治理子账进入财务系统时，还需要总账接口控制。每一批次应具备子账到总账映射、借贷或余额平衡、截止日期、币种、异常队列、关账责任、会计凭证链接和审计抽样路径。贡献或权益事件完整，不表示会计分录已经完整；跨期差异、失败支付和后续冲正必须进入关账程序。

本章工具与图表

本章的制度关系可结合附录二、附录六使用。附录用于形成可填写、可核对的工作成果，不能把模板中的默认项视为已经生效的组织规则。

图25-1　利益相关者资本治理整体技术架构。 业务、证据、规则、权益和治理分层连接；链上链下按验证价值和责任配置

本章注释

1. [SRC-076] 万维网联盟（W3C）：Verifiable Credentials Data Model v2.0。原文或官方页面
   • 本章引证：W3C：可验证凭证数据模型 2.0。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：W3C：可验证凭证数据模型 2.0、W3C：可验证凭证中的选择性披露与隐私考虑、W3C：可验证凭证的参与角色与验证边界、W3C：可验证凭证的验证与业务判断、W3C：可验证凭证与数据最小化。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。