Service Node

Service Node 是 AIDC 的服务交付单元：一个部署在客户组织里、持续运行的自治服务单元。它把服务从"交完就开始过时"的交付包，升级为"越用越值钱"的运营资产——知识沉淀在节点里、权限有清晰边界、每一步操作可追溯、服务质量随使用持续上升。

// 一句话理解

把一项咨询或外包服务装进一个会持续运转的"数字部门"：它有自己的资料柜（文件系统）、岗位说明书（Agent 角色）、操作手册（SOP）和工作台账（审计日志）。项目结束后团队不撤场，这个部门留在企业里继续工作、继续变好。

// 核心命题

AIDC Operating Thesis 第四条判断：服务应该从交付包升级为 Service Node——可部署、可审计、可演化。交付的终点不是一份文档或一段代码，而是一个在客户组织里持续运行、持续积累的服务单元。

从交付包到 Service Node

传统咨询与外包的交付形态是"交付包"：项目结束时移交一批文档、模型或代码，然后团队撤场。交付包的问题不在质量，而在形态——它是静态的，交付那一刻就开始贬值：流程变了没人更新，经验留在顾问脑子里，企业既无法审计当初的决策依据，也无法在原有基础上继续演进。每一次新需求，都意味着重新立项、重新付费、重新让一批新顾问熟悉业务。

Service Node 把同样的服务内容装进一个可运行的结构里。对企业而言，这是从"买一份报告"到"添一个部门"的转变：

维度	交付包	Service Node
形态	静态文档、代码、模型	持续运行的自治服务单元
知识	散落在交付物和顾问记忆中	沉淀在节点文件系统与 Ontology 片段中
责任	项目结束即责任终止	Agent 角色对节点内文件与流程持续负责
审计	无法回答"当初为什么这样做"	每个动作写入 Action Log，可回放、可复盘
演化	交付即过时，更新需重新立项	通过 proposal-first 流程在运行中持续演化
价值曲线	随时间贬值	随使用增值

Service Node 的组成

一个完整的 Service Node 由六个部分组成——就像一个正规部门必须同时具备职责说明、办公场所、资料档案、操作规程、在岗人员和工作台账。缺少任何一个，节点就退化为传统交付物：

服务定义Service Definition

声明该节点提供什么服务、服务对象是谁、质量标准是什么、与哪些其他节点协作。服务定义是节点的"合同"，也是部署与验收的基准。

运行环境Runtime Environment

节点运行在隔离的 AWS 环境中：EFS 承载节点工作文件系统，S3 承载对象存储、归档和版本化，VPC 与 IAM 划定网络和身份边界。详见 AWS 部署。

上下文Context / Ontology Fragment

节点持有一份内部 Ontology 片段——本服务涉及的对象、关系、动作和历史决策的"数字台账"。Agent 通过 Context Gateway（企业信息的"前台"，按任务与权限分发资料）获取最小可用上下文，既不过宽，也不过窄。

SOPExecutable Procedures

服务的重复步骤被沉淀为可执行的 SOP 文件，存放在节点文件系统中。SOP 是节点的"操作手册"：人和 Agent 都按同一份手册执行，执行偏差会被观察并触发演化。

Agent 角色Agent Roles

节点内的 Agent 系统由多个角色组成——例如执行角色处理任务、评估角色检查质量、Steward 角色维护 Ontology 片段。每个角色像员工一样有明确负责的目录与边界，参见 Agent 即文件管理者。

审计Audit

节点内所有状态变更通过受控 Action Type 提交并写入 Action Log（企业的操作台账），绑定发起者、Agent 版本和上下文包版本；本地审计缓冲保证即使中央日志短暂不可用，审计链也不中断。

与 Agent Cell 的关系

Service Node 与 Agent Cell 是同一事物的两个视角：Agent Cell 是技术视角的最小自治部署单元——可以理解为 AI 员工的"独立工位"（运行时、文件系统、权限适配器、事件接口、审计缓冲）；Service Node 是服务视角的最小交付单元（服务定义、SOP、Agent 角色、Ontology 片段）。

承载关系 — 每个 Service Node 由一个或多个 Agent Cell 承载。简单服务一个 Cell 即可；高负载服务可以水平复制多个 runtime worker。
边界一致 — 节点的服务边界与 Cell 的权限边界对齐：授权一个节点，就是授权它的文件系统、上下文索引和工具范围，详见权限模型。
故障隔离 — 单个节点不可用只影响该服务，不拖垮全局系统；同 Cell 的其他 worker 可接管队列任务，详见可靠性模型。

// 治理规则

节点之间默认隔离，不共享文件系统。跨节点协作必须通过四条受控通道：事件（Event）、共享摘要（Shared Summary）、Ontology Link 和受控 Action Type。任何绕过这四条通道的直接访问都是治理违例。

节点间协作

多个 Service Node 在同一个企业语义层下自治协作——就像各部门在同一套公司制度下分工合作：中央不接管执行，只维护语义、身份、策略和审计。四条协作通道各有分工：

事件 — 节点订阅企业事件并发布执行结果，事件总线支持重试、死信队列和幂等消费；异步协作不要求双方同时在线。
共享摘要 — 跨节点读取不暴露原始文件，而是传递经权限过滤的对象摘要；敏感细节留在源节点内。
Ontology Link — 跨节点的对象关系（例如"线索—决策"）通过 Link Type 显式建模，关系本身即访问依据。
Action Type — 一个节点请求另一个节点改变状态时，必须提交受控 Action Type，由对方按策略执行并记录审计——相当于部门之间走正式审批流，而不是私下改对方的台账。

客户视角下的生命周期

对客户而言，引入一个 Service Node 不是启动一个项目，而是部署一台会自己变好的"服务机器"。生命周期分四个阶段：

部署（Deploy） — FDE 通过客户发现找到真实流程，初始化节点：建立文件结构与 Harness、写入服务定义与首批 SOP、配置 Agent 角色与权限边界、接入隔离运行环境。验收标准是节点能独立完成第一类任务，实施步骤见部署 MVP。
运营（Operate） — 节点进入日常运行：Agent 按 SOP 执行任务，人类按权限介入关键审批，每个动作进入 Action Log。客户随时可以审计"谁、基于什么上下文、做了什么"。
演化（Evolve） — 运行数据驱动自演化闭环：失败、接管点和上下文缺口被观察、诊断、提案、审批，灰度验证后更新节点的 SOP、提示策略和 Ontology 片段。服务质量随使用上升而不是衰减。
沉淀（Compound） — 节点积累的语义、SOP 和 Agent 行为成为客户的组织资产：可移交给新员工或新 Agent，可复制为同类服务的节点模板，可作为下一个节点的部署起点。沉淀写在文件系统里，不随任何人的离开而流失。

// 示例场景

某 B2B 企业部署"线索研究"节点：部署期 FDE 把销售团队的线索甄别流程写成 SOP 并配置研究 Agent；运营期 Agent 每日产出线索摘要，销售主管在节点内审批高价值线索；三个月后演化机制发现"竞品动态"是高频上下文缺口，节点自动提案新增对应对象与检索规则；半年后该节点的文件结构与 SOP 被复制为第二个区域团队的部署模板。同一份服务，四个阶段，价值逐期累积。

哪些服务适合升级为 Service Node

并非所有服务都值得节点化。判断标准是服务的"重复度"与"沉淀价值"。以下检查清单帮助管理者快速评估——满足的条目越多，节点化的收益越高：

流程重复发生 — 服务按周或按月持续产出，而不是一次性的报告或方案；
知识值得沉淀 — 执行过程中产生的判断、案例和数据，对未来同类决策有复用价值；
有明确的质量标准 — 服务结果可以被定义、被验收，可写入服务定义作为部署与验收基准；
需要审计与合规 — 业务涉及审批、风险或合规要求，需要随时回答"谁、依据什么、做了什么"；
有复制空间 — 同一服务未来可能扩展到其他团队、区域或业务线，节点模板可直接复用。

若一项服务只满足一两条，先用传统交付即可；满足三条以上，Service Node "随使用增值"的价值曲线将明显优于一次次重新立项。从评估到上线的实施路径，见部署 MVP。