Service Node

Service Node 是 AIDC 的服务交付单元：一个可部署、可审计、可自演化的自治节点。每个节点同时拥有自己的文件系统、Agent 运行合约、内部 Ontology 片段、审计日志和演化机制——服务不再是一次性的"交付包"，而是一个持续运行的系统。

// 核心命题

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 是技术视角的最小自治部署单元(运行时、文件系统、权限适配器、事件接口、审计缓冲);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 被复制为第二个区域团队的部署模板。同一份服务，四个阶段，价值逐期累积。