在《软件的边界，不是业务的边界：为什么需要企业 OS》中，我讨论了如何围绕完整业务重新组织系统。继续往下做，会遇到两个问题：一家企业建立的业务模型，有多少可以被同行复用？一项业务跨过公司边界以后，能不能继续衔接？
前一个问题关系到建设成本，后一个问题关系到产业协作。企业 OS 向产业 OS 延伸，来自这两个方向的汇合。
一、行业软件一直想做复用，难在没有拆清差异
无论本地化软件还是 SaaS，沉淀行业模型、减少重复实施，一直都是大家想做的事。困难在于，项目中收集到的“客户需求”，经常混合了来源完全不同的内容。
以设备采购验收为例，客户可能同时提出：必须上传产品证明材料，由设备科负责核验，超过一定金额要增加一道审批，最后还要给院长发一份汇总。
这些要求有的来自行业规定，有的取决于人员和部门设置，有的属于内部管理制度，还有的只是某位管理者希望怎样看信息。落到需求清单里，却很容易都变成字段、流程节点和通知配置。
拆不清时，一种常见解法就是把选择留给客户：字段可以自定义，流程可以自定义，权限和通知也都能配置。工具越来越灵活，每家企业仍然要重新判断应该怎么搭。这个问题在《系统实施为什么变成了配置地狱》中已经展开过。
配置项是承载差异的手段，配置之前仍然需要知道差异从哪里来。
例如，“由设备科核验”就可以继续拆开：企业需要完成资料核验这项职能，设备科是这家医院安排的承担者。换一家没有独立设备科的医院，承担关系需要调整，资料核验本身的要求却未必改变。
如果这些层次能够分开，下一家企业就可以从已有模型出发，识别自己的差异。建模仍然有成本，但其中可共用的部分有机会成为行业积累，不必由每个项目重新承担。
二、一项行业规则，会在不同企业里变成不同需求
医疗设备注册证是一个具体例子。
医疗器械实行注册或备案管理，购进时还涉及供货资质、合格证明文件的查验及记录要求。以下以需要注册的产品为例。
医院采购一台设备，需要核对产品的注册信息，以及它与实际交付型号的对应关系。这会进入采购验收要求，落实为资料清单和核验记录。
供应商面对同一件事，看到的是另一组工作：找到相应产品的注册证及相关文件，按医院要求整理并提交。产品卖给另一家医院，又需要准备一次。
后续审计检查这笔采购时，还可能要求查看当时的资质材料和查验记录。医院于是再从采购系统、附件目录或纸质档案中寻找依据。
如果分别向这几方收集需求，会得到“验收清单管理”“供应商资料管理”“审计材料查询”等功能。但它们有一部分共同来源：同一项行业要求，在不同主体的工作中展开了。
因此，模型里需要明确的不只是“有一个注册证附件”。还需要知道它对应哪个产品、覆盖哪些型号，以及本次交付和核验引用的是哪份材料。
一张证书可以覆盖多个型号，同一型号又可以有许多台实际设备。如果每台设备都只上传一份文件副本，后续很难判断它们是否引用了同一份依据，也难以识别型号不匹配或材料缺失的问题。
这些对象关系与适用规则，本来就有行业共性。 它们可以被共同维护，再由各家企业补充自己的验收要求。某家医院在某次采购中收到了什么、谁完成核验，则属于具体业务记录。
三、共同定义，让上下游的工作接起来
假设一家供应商向三家医院销售同一型号的设备。医院分别使用自己的采购或资产系统，供应商需要按三种表格格式填写产品名称、型号和注册证号，再重复上传同一组产品材料。
如果双方能够使用可对应的产品定义，供应商就可以维护一份产品资料，在不同交易中引用，并按各家医院的具体要求补充缺项。医院接收后，将这些材料关联到自己的采购与交付记录，再完成本院的核验。
这里可以复用的是产品资料及其对应关系。每家医院仍然需要形成自己的查验结果，并保留当时采用的材料版本。供应商后来更新了文件，也不能覆盖过去验收时的依据。
审计需要检查某台设备时，就可以从设备找到采购记录，再追溯到当时提交的材料和核验结果。原本分散在几套系统里的工作，有了能够衔接的业务关系。
这也是产业 OS 的含义：可复用的行业模型，进入真实的跨企业业务，成为参与者共同工作的基础。
它同时减少两类重复。同行不必重新定义同样的行业要求；上下游也不必在每次交易中从头辨认对方提供的是什么。各方共享的范围由实际协作和授权决定，例如供应商提供本次交付所需的资料，医院保留自己的内部审批记录。
AI 进入以后，更需要从产业 OS 的范围考虑这套基础。
供应商的 Agent 准备注册资料，医院的 Agent 检查验收材料，审计助手再核查采购依据。如果它们分别读取法规、解释要求、辨认产品，就会重复完成同一部分工作，还可能得出不同口径。
共同维护的行业规则和产品定义，可以让这些 Agent 在已有依据上处理各自的任务。医院的 Agent 发现某个交付型号没有对应材料时，可以明确提出缺项；供应商的 Agent 则根据同一个产品标识寻找资料，提交后继续原来的核验事项。
参与者越多，这部分基础越值得共同建设。新增一个 Agent，可以继承已有的业务定义，再获得完成任务所需的授权。
四、组织架构不同，不等于职能需要从头定义
谈到行业复用，一个常见疑问是：每家企业的部门设置、人员规模和管理方式都不一样，怎么可能使用共同模型？
需要先看企业在产业价值链中承担什么功能。
设备制造商需要把产品生产出来，经销商承担供货与交易服务，医院采购设备用于诊疗。它们需要的模型有所不同。即使处在同一行业，也应当先区分所处环节与业务模式，再讨论哪些内容可以复用。
但对于处在相近位置的企业，组织差异并不意味着业务职能完全不同。
一家设备供应商可能由销售兼顾交付跟进，另一家设有专门的交付部门。两家都需要确认客户要求，并将约定的设备和资料交付给客户。人员增加后，原来由一个人兼顾的工作可以拆给不同岗位，交付责任仍然需要被完整承接。
医院也是如此。资料核验可能由设备管理人员负责，也可能由采购人员与技术人员共同完成。应当核验什么，可以来自共同的行业规则；由谁核验、谁处理异常，则结合本院条件安排。
《设计 Agent 之前，先弄清任务从哪里来》从组织在价值网络中的功能追溯任务来源；《讨论哪里能用 Agent 之前，先重新理解职能和组织分工》进一步区分了职能定义与职责分配。这两个层次，也为行业模型的复用提供了依据。
先明确产业分工中需要完成什么功能，再结合企业资源和管理选择，决定怎样分配。
客观条件与管理偏好也可以分别表达。人员少，需要一人兼任多项职责；负责人希望某类事项必须经过自己确认，则是一项内部授权安排。两者都会影响运行方案，但不必因此重新定义产品、交易或验收这些基础对象。
今后，部分资料检查可以交给 AI，异常判断仍由人承担。调整的是职能的承担方式，共同模型可以继续使用。
五、AI 会重组分工，数字环境需要承载这种变化
今天设计 Agent，经常会把行业规则、公司制度和个人偏好一起放进 Harness、Memory 或提示词里。一个验收助手的指令中，可能同时写着“核对产品注册信息”“超过一定金额交负责人确认”和“汇总时先展示异常项”。
这三条要求分别来自行业规定、企业授权和使用者偏好。它们的适用范围、维护者和变化频率都不同。如果全部封装在某个助手里，换一家医院、换一位负责人，甚至再增加一个助手，都可能需要重新解释和调整。
前文拆分行业共性与企业差异的方法，同样适用于 Agent。行业要求由共同规则提供，企业制度落到本地的责任与授权关系，个人偏好影响具体交互。Agent 据此获得完成工作所需的依据，也能明确哪些事情可以自行处理，哪些需要交给其他主体。
但分清这些层次的意义，还不止于设计好今天的 Agent。
随着 AI 能力变化，原来的分工也会变化。供应商可以在交付前自动检查资料完整性，医院人员将更多精力用于异常核验；专业服务方也可能承接多家机构的资料预审。原来必须在企业内部设岗完成的工作，可能成为外部服务，一项职能也可能被重新拆分，由不同主体协作承担。
如果业务逻辑被写死在当前部门、公司或 Agent 的边界里，每次分工变化，都需要重新拆系统、搬数据、解释上下文。产业视角则让我们先看清这项工作为什么存在、依赖什么、需要形成什么结果，再决定由谁承担。
企业边界和 Agent 边界，都只是某一阶段对产业分工的具体安排。
这也意味着，产业 OS 的模型本身需要能够演进。当一项行业要求改变，可以找到受影响的工作；当 AI 能够承担新的职能，可以重新安排承担者；当某个环节已经失去必要性，也有依据将它取消。已经确认的产品事实和业务记录，则能够继续被后续工作使用。
因此，产业 OS 可以从一段很小的业务开始建设，但它的设计对象应当包含这段业务所在的产业关系。随着人、AI 与企业之间的分工不断调整，数字环境需要让已有成果能够被接续，让新的协作方式能够在其上生长。
产业 OS 更长远的价值，是让每一次能力进步都有机会转化为整个产业的分工改进，而不被原有的软件和组织边界挡住。