第17章｜从理论到GEO Service System（GEO服务体系）

一、方法论写得完整，不等于服务体系已经运行

前十六章建立了决策情境、用户与人工智能决策变量地图、命题—证据系统、缺口诊断、干预和测量归因。要把这些理论变成可交付服务，还需要回答另一组问题：谁负责生成对象，谁有权作出判断，模块之间如何交接，哪些条件必须人工批准，失败后如何停止和恢复，运行时读取的文件是否等于获批源版本。

如果这些问题只靠长提示词和对话记忆维持，Agent（智能体）很容易跳过前置门槛、混用对象、越级下结论，或者在另一次运行中采用不同规则。

但反过来，拥有一套结构完整的Skill（技能）文件，也不能证明DeepSeek Harness（深度求索执行框架）已经稳定遵循。静态资产、目录发现、真实调用、行为一致和业务结果属于不同证据层。

因此，本章讨论的不是“我们已经拥有一个完全验证的自动化系统”，而是：如何把已冻结的方法论转化为对象化、契约化、门控化、可审计、可回滚并等待真实行为验证的交付体系。

二、GEO Service System（GEO服务体系）的工作定义

GEO Service System（GEO服务体系）是一套围绕决策情境、命题、证据、观测、诊断、干预和结果对象组织的协作系统；它通过版本化Contract（契约）、Epistemic Permission（认识权限）、Human Gate（人工门控）、运行记录和学习回写，将GEO方法论转化为可复核交付。

它不是文章生产流水线，也不是一个“自动提高人工智能推荐率”的黑箱。它首先是一套认识和执行治理系统：让每个模块知道自己处理什么对象、可以观察什么、可以推断到什么程度、何时必须停止，以及输出由谁使用。

三、六条架构原则

四、体系不是“一个万能Agent（智能体）”

一个万能智能体看起来使用方便，却会同时承担事实采集、用户研究、命题审查、人工智能观测、诊断、执行和效果判断。职责越集中，越容易发生循环论证：智能体先猜用户关心什么，再按自己的猜测设计问题，然后用自己生成的答案证明诊断，最后评价自己的干预成功。

第二版体系采用职责分离。它不意味着必须长期运行14个独立智能体，而是先把14组不同的对象、权限和状态拆开。只有真正需要独立上下文、工具、持久状态或批准权的模块，才有理由由独立Agent（智能体）承载；其余可以作为同一执行环境中的Skill（技能）。

五、十四个目标Skill（技能）

模块数量是当前职责分离的工程结果，不是品牌卖点，也不是永远不能改变的理论常数。

六、主流程不是一条只向前的生产线

Project Intake（项目接入）
→ Decision Research（决策研究）＋Claim-Evidence（命题—证据）
→ Probe Design（探针设计）
→ AI Observation（人工智能观测）＋Public Information Audit（公开信息审计）
→ Gap Diagnosis（缺口诊断）
→ Intervention Design（干预设计）
→ Owned or External Execution（自有或外部执行）／No Action（不行动）
→ Measurement and Learning（测量与学习）
→ 诊断更新、报告与下一轮决策

流程允许停止、返工、降级和不行动。事实未知可返回接入或证据核验；测量失败返回测量设计；诊断被反证则更新诊断，而不是为了完成套餐继续执行。

Orchestrator（总控编排）负责路由与门控，不替代专业模块作出内容判断。

七、核心交付对象

服务体系不是通过“模块说完了”交接，而是通过版本化对象交接。对象依次覆盖项目与研究、命题与证据、探针与观测、诊断与干预、执行与测量，以及路由、门控、错误和不行动记录。每个对象都有生产者、消费者、版本、认识状态和最低字段；对象不合格时，下游不得靠推断补齐。

本章说明对象链与治理原则，不重复展开全部字段。22类当前核心对象、生产者、用途和禁止误读见附录B｜Core Object Dictionary（核心对象字典）。这些对象是当前工程表达，不是跨项目永远固定的理论常数。

八、Contract（契约）为什么比长提示词更重要

长提示词可以描述原则，却难以保证每次运行都完整遵守。Contract（契约）把方法论转化为输入资格、字段、状态枚举、错误代码、版本要求和输出权限。

例如，Diagnosis Record（诊断记录）不仅写“这是G2”，还要包含目标情境、原子命题、现实状态、证据要求、支持与反向证据、替代解释、反证条件和非缺口路由。Intervention Card（干预卡）不能只写“发三篇文章”，而要连接诊断、可控对象、策略目的、渠道适配、基线、护栏、停止和撤回。

契约的价值是让错误显性化。字段缺失不是语言问题，而是一个可阻断的状态。

九、八道强制Gate（门控）

1. Intake Gate（接入门）：主体、范围、授权、排除项和未知项明确；
2. Research Gate（研究门）：决策情境成立，User-DVM（用户决策变量地图）认识状态可解释；
3. Baseline Gate（基线门）：探针、运行条件、分母与缺失规则锁定；
4. Diagnosis Gate（诊断门）：差异不替代缺口，G1—G5具有资格与反证；
5. Intervention Gate（干预门）：真实性、授权、合规、伤害和业务资格通过；
6. Release Gate（发布门）：改变对象、执行者、版本和撤回路径明确；
7. Measurement Gate（测量门）：处理接收、比较资格、污染和结果成熟度明确；
8. Reporting Gate（报告门）：认识状态、因果等级和禁止措辞通过复核。

门控不是给系统增加流程负担，而是把不可逆错误挡在更早阶段。真实性、授权和伤害门不能被商业价值补偿。

十、认识权限如何阻止模块越权

采集模块可以记录企业陈述，不能把陈述升级为事实；研究模块可以形成Decision Situation Candidate（决策情境候选），不能用人工智能常识替代用户证据；观测模块可以记录答案行为，不能推断内部检索机制；诊断模块可以提出操作性诊断，不能选择有利于服务商销售的缺口。

执行模块只能实施获批组成项，不能自行改变目标命题；测量模块可以报告变化与有限贡献，不能用前后差异宣称因果；报告模块只能翻译获批结论，不能在面向客户时抬高确定性。

这种权限边界比“模型更聪明”更重要，因为它决定错误能否被及时阻断和追责。

十一、现有旧体系审计揭示了什么

旧体系已经拥有较完整的声明性骨架、12份业务Skill（技能）、部分探测工具和交付模板，但审计不能把它直接描述成12个已部署、可稳定执行的Agent（智能体）。

早期体系存在几类关键冲突：按站内与站外组织核心服务、使用固定等权AIVO（人工智能可见性优化）分数、存在“±8%”模拟精度表述、按媒体或内容类型暗示固定权威、以少量引擎结果称为收录、用上升趋势证明动作有效，以及把文章数量定义成主服务套餐。

这些做法已从第二版目标架构中移除。原因不是它们一定永远无用，而是当前缺乏足够证据支持其固定权重、精度、因果和跨场景承诺。

十二、从12个旧模块到14个职责模块

第二版不是简单增加两个Skill（技能），而是重新分配对象与权限：

• 把真实用户决策研究与查询生成分开；
• 把命题—证据审查从资产清单中独立出来；
• 把探针设计、运行和人工智能观测分开；
• 把公开信息审计与人工智能行为观测分开；
• 把缺口诊断与干预设计设置防火墙；
• 把站内和站外降为两类执行渠道；
• 把测量、归因和学习集中到独立生命周期模块；
• 把客户报告限制为翻译层，不允许新增分析。

重构的重点不是模块数量，而是让循环论证和越权路径失去结构入口。

十三、Authoring Source（编辑源文件）与Installed Runtime Copy（已安装运行副本）

历史运行基线中存在两类文件：

历史比对发现12个业务Skill（技能）中6个相同、6个不同。该结果证明：修改源文件不会自动同步到运行副本；运行行为审计必须以实际读取版本为准。

当前第二版体系保存在项目文件夹中，按照用户决定，不在本阶段复制到.workbuddy。未来由用户自行选择复制与安装时，必须重新建立全新的安装清单和散列基线，不能沿用历史结果。

十四、正确的安装与发布门

Approved Source（获批源版本）
→ Install or Copy（安装或复制）
→ Hash Equality Check（散列一致性检查）
→ Skill Discovery Check（技能发现检查）
→ Smoke Test（冒烟测试）
→ Runtime Manifest（运行清单）
→ Release Approval（发布批准）

运行清单至少记录Install Manifest（安装清单）、Source Hash（源文件散列）、Runtime Hash（运行副本散列）、Installed At（安装时间）、Installed By（安装者）和测试结果。

源文件正确不等于运行副本已更新，散列一致不等于模块可调用，可调用也不等于语义行为符合方法论。

十五、六种验证结论必须分开

六种结论不能互相替代。本章当前只能确认前几层的部分静态成果，不能宣称第五和第六层已经完成。

十六、当前V2（第二版）达到什么状态

当前14个Skill（技能）已经具备目录、前置元数据、输入资格、执行顺序、判定表、失败路由、输出字段、人工门控以及正反Fixture（测试样例）等结构。各模块已经不再是纯Policy Skeleton（政策骨架）。

总控具有结构状态机和门控评估器；探测运行模块具有Simulation-only Runtime（仅模拟运行时）；上游研究、命题证据、探针、观测、诊断、干预、执行、测量与客户报告均已完成相应Profile Test（剖面测试）或结构回归。

这使体系达到Deterministic Integration-ready（确定性集成就绪）与Candidate for DeepSeek Test（DeepSeek测试候选），但不等于Execution-ready（可执行就绪），也不等于DeepSeek Behavioral Validation（DeepSeek行为验证）已经通过。

十七、为什么行为测试仍然必要

静态测试可以检查字段、枚举、拒绝条件和样例输出，却不能完全回答智能体是否会：

• 在信息缺失时诚实保留Unknown（未知）；
• 抵抗客户要求伪造确定性的压力；
• 不把企业自述当成事实；
• 不把搜索索引写成人工智能已经检索；
• 不把缺口直接映射成文章和媒体；
• 在复杂多模块交接中保留版本和认识状态；
• 对不合格任务选择停止或No Action（不行动）；
• 在报告中遵守C0—C5 Causal Confidence（因果置信度）措辞。

所以Behavioral Validation（行为验证）不能由文件完整性替代。按照项目顺序，该测试已经被明确延期到白皮书、演示大纲和网站方案之后，不在本章提前执行。

十八、代理商和客户看到的不是14个模块

模块是后台治理结构，不应要求代账公司或终端客户理解全部工程细节。前台交付应围绕客户决策组织：项目边界、用户决策研究、企业事实与证据、人工智能观测、缺口诊断、干预方案、执行回执、测量结果、风险和下一步。

代理商可以负责客户关系、资料协调、业务边界确认和报告沟通；专业诊断、证据资格、干预审批、测量归因和方法更新仍应由相应角色与门控治理。具体合作模型属于V1.0（第一版）之后的独立商业化研究，不在本章或本版正文中展开。

“后台复杂、前台清楚”不是隐藏方法，而是把复杂性留在需要承担责任的地方。

十九、Client Report Package（客户报告包）

客户报告不是把所有内部对象直接导出，而是受认识状态和授权控制的翻译层。它必须说明项目边界、观测条件、事实与证据状态、缺口与非缺口、获批干预、实际结果、风险、不行动、允许的归因措辞以及下一决定。报告模块不能为了销售效果删除反向信息、提高因果等级或隐藏测试范围。

可直接复用的Client Report（客户报告）字段结构见附录C｜Method Templates（方法模板）；可用措辞与禁止措辞见附录D｜Epistemic Status（认识状态）与因果措辞。

二十、体系明确不再承诺什么

第二版明确排除：

• 固定等权的AIVO（人工智能可见性优化）总分；
• 模拟模式“±8%”精度承诺；
• 固定S／A／B／C全局权威等级；
• 某种内容类型天然“人工智能引用高”；
• 两个引擎出现即可称为“已收录”；
• 指标上升即可证明动作有效；
• llms.txt等任何无条件必做项；
• “人工智能信任我们”“模型敢引用”等不可观测内部状态措辞；
• 按5篇、10篇或20篇内容定义主服务套餐。

这些排除项构成产品诚信边界，也将成为代理商销售和客户报告的禁止承诺。

二十一、对服务运营的最低要求

每个项目应拥有统一项目编号、对象版本、路由记录、门控结果、错误记录、人工批准、执行回执、测量契约和项目登记状态。

失败、暂停、撤回、无法判断和不行动必须与成功项目进入同一Project Registry（项目登记）。Learning Write-back（学习回写）产生新版本、假设或复查任务，不静默修改历史记录。

任何真实发布、客户授权、因果措辞或重大风险决定都需要责任人。智能体可以提高结构化处理效率，不能成为责任消失的理由。

二十二、Minimum System Release Record（最低系统发布记录）

系统发布记录至少覆盖源版本、安装状态、发现与调用、行为验证、外部依赖、权限门控、发布决定和变更治理八组信息。它必须能够回答“批准了什么、实际运行什么、验证到哪一层、谁承担责任、失败后如何回滚”，不能只记录一次复制成功。

完整字段模板见附录C｜Method Templates（方法模板）中的System Release Record（系统发布记录）；版本冻结的权威顺序与变更限制见附录E｜版本冻结来源与限制声明（当前在线版未收录）。

二十三、本章明确否定的观点

• 方法论文档完整就等于服务体系已经运行；
• 14个Skill（技能）等于14个独立部署的Agent（智能体）；
• 文件存在即可证明可发现、可调用和可稳定执行；
• 源文件修改会自动同步到运行副本；
• 散列一致即可证明语义行为正确；
• 静态回归通过即可证明真实DeepSeek（深度求索）行为通过；
• 模拟运行可以证明真实引擎、真实用户或业务结果；
• 智能体可以用自然语言记忆替代对象契约和版本；
• 总控可以越权生成诊断或效果结论；
• 报告模块可以为了客户体验创造新分析；
• 站内、站外和内容数量应作为一级服务架构；
• 固定权威分、可见性总分和模拟精度已经获得验证；
• 行为测试延期等于行为测试已经通过；
• 用户未来复制文件后无需安装清单与散列核验；
• 网站代码属于本轮服务体系编辑范围；
• Skill（技能）结构完整即可产生Validated Pattern（已验证模式）。

二十四、当前仍然不知道什么

以下问题保持Unknown（未知）：

• DeepSeek（深度求索）在完整测试包中的行为遵循率与失败模式；
• 多模块长流程中的状态持久化、恢复和并发边界；
• 真实安装后的Skill Discovery（技能发现）、路由与调用稳定性；
• geo-probe-runtime真实适配器的目标平台与实现方式；
• 真实引擎观测中的工具、地区、账户和产品状态差异；
• 人工门控在实际团队中的职责分配和响应时效；
• 代理商转述方法边界的真实遵循情况；
• 不同行业项目对14个职责模块的裁剪方式；
• 系统结构完整度与交付质量、干预效果及业务结果的因果关系；
• 可升级为Validated Pattern（已验证模式）的真实项目门槛。

当前Validated Pattern（已验证模式）为空。

二十五、本章结论

GEO Service System（GEO服务体系）不是内容工厂，而是把决策研究、命题证据、人工智能观测、缺口诊断、干预、执行、测量和报告组织成版本化对象与权限门控的协作系统。

第二版通过14个Skill（技能）完成职责分离，但模块数量不是固定理论，也不代表14个独立智能体已经部署。当前系统达到确定性集成与DeepSeek测试候选状态，不能越级宣称行为验证、真实引擎验证或业务效果已经完成。

Source Correctness（源文件正确性）、Runtime Conformance（运行一致性）、Discoverability（可发现性）、Callability（可调用性）、Behavioral Conformance（行为遵循）和External Validation（外部验证）必须分别证明。未来用户复制到实际运行目录后，还需重新执行安装清单、散列、发现、冒烟和行为测试。

至此，V1.0（第一版）正文完成从理论到交付体系的闭环。代账公司等代理伙伴如何参与获客、资料协调、客户沟通和服务交付，将作为后续版本或独立商业化手册的研究入口，并继续受到本章的方法、权限与承诺边界约束。

本章图表

图17-1｜从理论对象到服务模块

重绘说明：上层展示决策情境、变量、命题、证据、观测、缺口、干预和结果；下层连接14个职责Skill（技能），强调模块围绕对象而非站内站外划分。

图17-2｜GEO Service System（GEO服务体系）主流程

重绘说明：展示接入、双研究链、探针、双观察链、诊断、干预、两类执行或不行动、测量学习与报告，并画出失败、返工和学习回路。

图17-3｜八道Gate（门控）

重绘说明：从接入门到报告门依次展示，每道门标出负责对象、人工批准和失败路由。

图17-4｜六种验证结论

重绘说明：将文件存在、源文件正确、运行一致、可发现可调用、行为遵循和外部业务验证画成六级证据阶梯，明确上一级不自动证明下一级。

图17-5｜源文件与运行副本双轨

重绘说明：左侧为获批源版本，右侧为实际运行副本，中间依次放置复制、散列核验、发现、冒烟、行为验证和发布批准。

图17-6｜后台14个模块与前台客户交付

重绘说明：后台展示细粒度职责和对象，前台压缩为项目边界、研究、证据、诊断、方案、执行、测量和下一步，说明后台复杂性不直接转嫁给客户。

表17-1｜十四个Skill（技能）职责与权限矩阵

采用本章第五节表格，补充每个模块的主要输入、输出与人工门控。

表17-2｜Minimum System Release Record（最低系统发布记录）

采用本章第二十二节的八组字段，为未来安装、测试和发布提供交接规范。