Bab 24 — Kolaborasi Lintas Organisasi dan Tata Kelola Ekosistem

第二十四章　跨组织协作与生态治理

共同创造并不总在一家企业内部完成。研发、生产、服务、传播与持续维护可能分布在不同组织，客户与供应商也可能参与能力形成和结果改进。参与主体增多，贡献就更需要被理解和核验；但每家组织拥有自己的资源、责任与治理程序，不能因为共同使用一本账，就被视为合并成同一个企业。

上一章讨论审计、纠错与责任追溯。当证据和权益穿过组织边界，这条责任链会遇到新的问题：谁能够证明某件事已经发生，谁有权评价其作用，哪些组织愿意承认该结果，以及出现错误时由谁纠正并履行后果。本章以跨企业贡献、共同规则、系统互认和平台权力为线索，讨论区块链怎样支持协作而又不抹去组织之间真实的制度边界。

生态治理在本书中指围绕共同事业形成的多方规则与责任安排，并不预设所有参与者服从同一中心，也不等于任何平台公开接入后就自然成为共同体。它的质量要由参与者能否明确协作条件、检验相互承诺、处理分歧和有序退出判断。

一、跨企业贡献记录与协作关系

跨企业贡献的起点是共同任务，而不是一份统一积分表。组织可以共同确定某项成果的目的、参与范围、交付条件和验收方式；也可以在已有业务合同之上增加可核验的协作记录。只有先说明参与者各自承诺做什么、如何证明完成，后续记录才知道在描述哪一种共同创造。

贡献事件应分别保留投入、交付、采用和结果。某企业投入研发资源，另一企业完成生产适配，客户实际使用后提出改进要求，都可能与最终成果有关；它们并非一种可以凭次数直接相加的动作。事件记录需要指明发生时间、关联任务、作出者、受领或验证者、证明材料及状态，避免同一事实在多家企业内部被重复登记后又被当作多项独立贡献。

跨组织证据往往来自不同位置。交付方可以出具成果与过程资料，接收方可以确认收到及使用范围，第三方可以核查特定质量指标。每种签名证明其签署者作出了什么陈述，不保证所有其他主体已经同意该陈述的完整经济意义。制度应要求证据来源与证明范围一起流转，使之后的评价者看得出还缺哪一环。

面对共同成果，还要区分归因与分配。多方共同设计、反复修改的一项成果，可能无法精确切成各自独立生产的份额。可行的制度可以在事前约定贡献类别、共同贡献的确认程序以及无法分割部分的分配原则；也可以保留未决状态，等待证据充分时再判断。数字记录支持复核，但不会自动解决因果归属的难题。

个人与组织的关系也需分层。员工在企业项目中完成工作，其个人行动、企业承担的资源投入，以及企业对外承诺交付，分别属于不同事实。生态账本可以在必要范围内识别贡献者与所属组织，不应直接把个人业绩改写为对另一企业的债权，也不应因为企业对外结算，就删除实际参与者的历史贡献。

贡献记录与资本形成、权益成立之间仍有制度门槛。某合作方完成了交付，可能取得合同约定的价款；其工作又可能帮助共同事业形成持续能力，但这一判断需要组织吸收、持续使用与风险承担的证据。合作方是否进一步参与未来收益或治理，要依据另外的有效安排。跨企业“贡献分”不能自行转换为所有成员企业的股权或收益权。

共享账本适合维护多方需要共同核对的事件状态，特别是双方都不愿完全依赖对方单独保管记录时。它可以记载提交、承认、异议、修订及相应时间，并让授权主体核对前后版本。但共同记录解决的是证据可得与操作一致的一部分问题，不决定证据是否充分、服务质量是否达到标准，也不代替各企业原有的财务与业务审查。

为了使记录能够跨组织使用，应建立共同的任务与事件标识、签署主体识别和必要的版本关系。标识不只是技术编号，更要让各方分辨同一交付是否在不同系统中重复出现。身份映射发生变化时，也要保留当时哪一家机构、哪位有权代表以何种身份作出确认。

证据共享还受保密与个人信息边界限制。生产数据、定价条件、员工资料和客户行为，不宜因为一方希望“上链透明”就对整个生态公开。各方可以共享必要摘要、确认结果及受控访问办法，对详细材料规定持有人、保存期和审查条件。参与者能核验证据是否对应原始材料，比所有人同时看到全部原始材料更重要。

跨企业记录的最终目的，是降低对共同创造的解释成本。当每方都能说明自己承担了什么、确认了什么、仍对什么存疑，协作才有机会从一次交易延续为跨期的能力与关系。这样的关系可能成为利益相关者资本的组成部分，但其存在和持续作用，仍要在实践中检验。

二、共同规则与各组织自主权的衔接

共同事业需要一组相互承认的规则：谁可以加入，哪些事实可以共享，怎样确认交付，争议由谁受理，系统如何升级，以及退出时怎样处理未了事项。与此同时，每个组织仍要管理自己的人员、预算、商业秘密和法定职责。生态规则要能约束共同协作的接口，也应清楚划出各组织保留自主决定的范围。

共同规则可以按层次组织。基础层约定成员资格、数据与权利边界；协作层约定任务发布、证据提交、验证和评价；结算层约定资源、支付、对账与违约处理；治理层约定提案、表决、监督及修订。分层使参与者知道某项协议改变的是共同接口还是企业内部管理，减少“加入生态即接受全部未来规则”的不确定性。

权力来源不能由平台界面单独决定。平台可以提供发起提案和计票功能，是否有权代表一家企业同意规则，仍须由该企业的有效授权确定。某个员工拥有项目账户，不一定能承诺企业承担新增支付义务；企业代表能够签署协作记录，也不因此取得更改所有成员权益结构的权限。

共同规则还应说明哪些决定需全体成员同意，哪些可以由类别代表决定，哪些可以交由有授权的运营机构执行。业务数据格式更新和改变风险分担方式，影响程度不同，不能只因为两者都可写入“参数”，就使用同一级别的审批。对应的通知期限、异议程序和生效条件，也要与影响范围相称。

组织自主权需要以明确保留事项表达。是否接受某项具体任务、内部由谁参与、如何核算本企业成本、对外承担超过既定范围的义务，通常都需要组织自身的决定。共同规则若拟限制这些权力，应说明限制的目的、内容及得到各方同意的程序。共享基础设施可以降低重复协调成本，却不能替任何企业承担它没有接受的责任。

反过来，自主权也不是随意否认共同承诺的理由。企业已经按有效程序接受的交付、保密、结算或纠错义务，应按其范围继续履行。成员内部人员变更、信息系统替换或预算重新安排，可能影响操作路径，却不自动取消对其他参与者已经形成的请求。生态治理应同时保护成员的决定边界和共同承诺的稳定性。

有些规则需要在不同组织内部转化为各自的操作要求。共同规定由双方向指定材料签收，接收方就需要安排谁有权签收；共同规定错误数据应在一定期间内复核，各企业也需配置相应受理职责。共同文本获批，不等于成员内部已经具备执行能力。生效前应核对身份、预算、流程及数据接口是否就绪。

共同规则可以采用版本管理，但成员采用时间可能不同。过渡期要说明旧任务依旧规则还是新规则处理，哪些成员和业务已正式切换，涉及多个成员的任务怎样避免一方采用新口径、另一方采用旧口径。已成立的请求不能因为某家企业更新得较慢便成为无主状态；必要时应保留兼容期和负责协调的主体。

治理代表性同样需要设计。大企业承担较多资源风险，小企业可能承担关键专业工作，个人参与者又可能缺少正式成员席位。权重可以结合事项和责任配置，但应防止出资最多者或掌握平台者在所有议题上都取得无限决定权。受影响者至少需要适当信息、表达和救济渠道；对于直接改变其既有权益的安排，还需满足相应的有效程序。

一个成员参与多个生态时，可能面临义务冲突、资料重复提交和身份滥用问题。共同规则应允许有依据的保密与最小披露，也要规定哪些共享成果不得被重复承诺给相互排斥的主体。是否允许并行合作，应依具体承诺和竞争关系判断，不能笼统要求所有参与者把全部业务都置于同一平台之下。

共同规则的边界可概括为：在多方确实需要共同核验、协作或履行的事项上形成共享秩序；在各组织依法依约独立承担的事项上保留可识别的自治空间。只有这两部分都清楚，生态才可能在扩大时保持合作，而不以规模增长掩盖权力和责任的模糊。

三、跨系统互认、结算与争议解决

互认首先要说清“认”的是什么。甲企业确认一个人曾参与项目，乙企业可以接受这一历史事实的证明，却仍可依据自己的规则决定该事实是否满足任职资格；丙企业可以接受某项交付确已完成，却不一定承担甲企业对交付者作出的收益承诺。身份、事件、资格、评价和具体权利，处在不同层次，不能因为都能表示为数字凭证便一次性互相继承。

第十三章已经说明凭证角色及其验证边界。跨系统互认在此增加的是组织责任：接收方仍须决定信任哪一签发者、为哪个用途接受哪项声明，以及依赖错误时由谁承担复核与纠正义务。

互认安排需要公布最小必要条件：发行主体是否在授权范围内，凭证对应的对象和任务是什么，状态是否仍有效，证明材料可以在哪里核查，以及接收方采用什么业务判断。某些证明只需核验是否满足阈值，另一些则要查看完整的审查报告。若接收方要求超出用途的全部历史资料，互认可能降低参与者对信息使用的控制。

不同系统对同一词语的理解也可能不同。“完成”在一方系统中表示提交材料，在另一方系统中表示验收合格；“成员”可能只表示平台注册，也可能表示持续承担义务。互操作不应仅靠字段名称相同。各方需要共同的数据定义、状态映射与版本说明，并允许接收方标注“已核验格式、尚待确认业务含义”。

身份互认同样需要识别控制与主体的差别。分散式标识符可以帮助系统定位某个标识及其验证方法，但持有控制手段的人未必就是被标识的自然人或组织；代理、托管和集团关系都可能使两者不同。W3C 的 DID 规范也区分标识所指主体和标识控制者。生态互认应在必要时补充组织授权、代理关系和身份恢复程序。W3C：去中心化标识符规范〔1〕

跨系统状态同步则需考虑时间。甲企业撤回一项错误凭证，乙企业在撤回前已依据它作出决定，后续如何修正，不能只靠让查询接口返回“已撤回”。各方应约定状态更新时间、通知责任、既有处理的复查范围和新的更正记录。无论采用共享账本还是多套互连账本，状态到达各方的时间差都需要被制度承认。

结算比互认更进一步：它改变资源或债务关系。合作方之间可能按任务逐笔支付、定期汇总、在有依据的范围内相互抵销，或由共同资金池按约定条件支付。每种方式都需要明确支付义务人、受领者、计价对象、期间、费用和无法按期支付时的处理。账本能显示“待结算”额度，并不意味着成员企业已经实际交付相应资源。

若共同平台代为清分或托管资源，应区分它是在传递指令、代理收付款，还是自身承担兑付义务。平台展示的余额也需说明是成员间的应收应付、平台保管的资产，还是受其他条件限制的额度。不同关系对风险、监督和审计的要求不同；平台不能只通过统一界面把多个义务主体写成一个没有责任边界的“生态账户”。

跨组织结算要能与各方内部账目分别对接。一项任务在共同账本显示交付合格，付款方仍需核对内部采购或费用依据，收款方还需核对实际收款和自身收入条件。结算单、链上交易和银行回执可以互相引用，但应分别保留证明范围。若发生退款、部分支付或计价争议，双方系统都需要能够找到同一笔原始请求与后续调整。

对不同资产或计量单位的结算，还要说明换算来源和时点。把通证参考价格直接乘以数量，不能自动形成应付法定货币金额；一方愿意接受某种数字单位，也不意味着另一方有权以其替代原约定的支付对象。资源准备、价格波动、手续费与失败重试，都需要通过有效安排分配风险。

争议解决必须在协作开始时有入口。争议可能涉及交付事实、共同贡献归因、凭证真伪、规则解释、结算金额或支付失败；各类问题所需证据和有权处理者不同。可以先由任务双方核对业务事实，再按共同规则进入复核、调解或其他有效程序。若必须由特定机构作出最终决定，应说明其权限来源、适用范围及与各成员既有争议程序的关系。

跨组织争议尤其需要避免任何一方控制全部证据和程序。交付方持有工作过程，接收方掌握使用结果，平台保存状态与接口日志，三者共同构成判断材料。制度应规定必要的保全、提供和保密责任；不提供材料的后果也应有依据。审查者需要能够辨认资料来自哪里，而不是只接受一方生成的单页结论。

结果执行仍需回到各个义务主体。共同机构可以认定某项记录应更正，却需要明确由谁修改各自系统、谁通知下游接受过该凭证的组织，以及谁补付或返还资源。纠错状态应保持跨系统可见，不能在共同账本标记“争议解决”之后，让受影响者继续面对各成员系统中互相矛盾的余额。

互认、结算和争议解决形成一个闭环：先规定哪些证明可被接受，再确定由谁按照何种义务履行，最后使错误或分歧有可执行的处理路径。若只完成第一步，共享记录会提高传递速度，却未必提高合作可靠性。

四、平台权力、基础设施控制与生态退出

生态平台通常掌握加入入口、任务发布、数据格式、证据展示、结算接口和用户联系渠道。这些能力可以降低协作成本，也可能形成新的权力集中。即使平台声称账本由多方共同维护，若只有一家机构能够批准身份、升级协议或关闭关键接口，参与者实际依赖的仍可能是单一控制点。

观察平台权力，不能只看链上治理票数。谁决定哪些组织可以加入，谁能修改贡献评价参数，谁能冻结争议账户，谁掌握原始业务资料，以及谁可以阻止成员读取历史记录，都会改变协作结果。某个操作没有进入智能合约，不代表它对生态没有治理影响。

基础设施控制还可能通过技术设计固化。独占的数据格式、无法替换的身份服务、只在平台内部有效的贡献编号和封闭的结算接口，使成员即使在名义上保留退出权，也难以把既有业务带走。评价平台是否开放，应检查接口、数据可携带性、历史凭证的可验证性和替代服务接入条件，而不只检查源代码是否公开。

共享基础设施仍需要运营者。有人要维护节点、更新软件、处理身份争议、承担安全费用并协调不同系统的故障。治理的目标不是假装这些权力不存在，而是公开它们的范围、资金来源、监督方式和更换程序。运营者可以获得与职责相称的报酬，同时必须说明其服务质量、利益冲突和不履责时的替代方案。

平台参与市场交易或自行持有大量权益时，更需把运营职责与自身利益区分。若平台决定评价标准、掌握分配数据又能从发行或交易中获益，就需要特别检查其是否利用信息和程序优势改变分配。必要的披露、独立复核和受影响成员参与，可以降低权力滥用；单纯宣布“规则写在链上”并不足以解决这些关系。

平台费用也要接受共同监督。交易、验证、存储、争议处理和退出迁移可能分别产生费用。参与者应知道收费对象、调整权限与实际服务的对应关系。过高或不可预见的迁移费用，会把退出权变成纸面承诺；将治理成本全部转嫁给较弱成员，也可能让他们无法真正参与共同决定。

生态退出需要同时回答成员与参与者两个层面。企业退出共同平台，可能结束未来任务，但其已接受的交付、保密、结算、数据保存和争议处理义务仍需按有效安排完成。个人在成员企业或平台上停止活动，也不应自动失去已经形成的请求。退出程序要把未来合作终止与历史关系结清分别列明。

迁移时，成员应能取得自己有权保留的业务资料、凭证、审计证据和未了事项清单，并验证导出材料与原记录的对应。平台也要保护其他成员的商业秘密与个人信息，因此“可携带”并不等于复制全体数据库。共同任务的证据若由多方共同维护，应预先规定各方在退出后仍能核验什么、保留多久以及如何请求必要材料。

退出权还需要资源与技术条件。若支付请求只能通过平台内部钱包提出，成员离开后必须有替代办理方式；若某项身份凭证依赖即将停用的服务，应提供适当验证或迁移期限。运营者停止服务、成员不愿继续合作或生态治理发生根本分歧时，也需要保证历史关系可审计、未付请求可追踪、正在进行的任务有明确处置。

对于形成网络效应的生态，成员越多，单个成员退出越困难。共同标准与可替换接口可以降低这一成本，但也可能需要较高的初期协调投入。是否采用统一平台、联盟式基础设施或可互认的多套系统，应由实际协作关系、信任结构和运营成本决定，而不能把“去中心化”当作免于比较的结论。

本书提出一个需要检验的方向：让生态治理具有可迁移的制度连续性。参与者应能够在不抹去历史事实、不重复取得同一项权益的前提下，更换服务提供者并维持可核验的请求。检验这一方向，需要观察真实迁移所需时间、成本、资料完整性、结算不中断的程度以及弱势成员能否使用退出渠道；仅仅开放一个“导出”按钮，还不足以证明退出可行。

跨组织协作真正形成长期资本，依赖的是参与者可以共同维护的能力、相互理解的规则和持续可信的关系。区块链使记录与部分执行跨越企业边界，但共同事业是否正当有效，仍取决于各组织能否清楚承担承诺、分享决定并在分歧中保持可履行的秩序。生态越大，这些制度安排越不能被单一平台的增长指标取代。

下一篇将进入系统构建。第二十五章从整体技术架构出发，讨论业务、证据、规则、权益与治理模块怎样连接，链上与链下如何分工，以及系统如何在保持制度边界的条件下与企业已有设施协同运行。

定稿补强：跨组织规则与基础设施权力

跨组织协作协议应明确主体、准据法、管辖或仲裁地、送达、证据、临时措施、破产、权利优先和退出后存续条款。技术互认只能说明系统能够读取或验证某种状态，不能保证合同、担保、登记或裁决在另一法域自动获得承认。

生态治理还要识别标准维护者、身份根运营者、接口提供者、预言机、结算入口和软件升级者。共同协议应公开依赖、费用、变更程序、数据可移植格式、替代运营者和退出测试。所谓分叉权只有在参与者能够取得数据、软件、标识映射和运行能力时才是现实选择；制度应披露实际迁移成本，防止互操作接口形成新的基础设施垄断。

本章注释

1. [SRC-073] 万维网联盟（W3C）：去中心化标识符规范。原文或官方页面
   • 本章引证：W3C：去中心化标识符规范。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：W3C：去中心化标识符规范。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。