企业官网建设流程全解析

摘要：模型会推理，并不代表任务能可靠完成。本文结合 Hermes、Codex 与 DeepSeek Harness，梳理 Agent loop、Turn/Step、工具调度、上下文压缩、长期记忆、审批与沙箱，并用 7 张架构图说明三种 Harness 的设计重心与组合边界。

本文基于 2026-10-03 核对的源码快照与官方文档。图示为概念抽象，具体功能以对应版本和配置为准。

阅读导览

本文沿着一条主线展开：模型提出下一步，Harness 组织执行、保存状态、处理反馈，并判断任务如何继续。

1. 为什么需要 Harness：它填补了什么工程缺口。
2. 共同运行机制：Turn、Step、工具循环、上下文与状态。
3. Hermes：围绕长期助手组织记忆、技能和多入口。
4. Codex：围绕执行内核组织协议、权限和任务生命周期。
5. DeepSeek Harness：通过插件装配可替换的运行时。
6. 横向比较：三者如何扩展、组合与验证。

01 · 为什么需要 Harness

1.1 模型与真实任务之间的缺口

语言模型可以分析问题、生成文本，并提出工具调用意图。但真实任务还需要执行程序、读写文件、调用服务、等待结果、处理异常，甚至跨越多次对话和进程重启。

Harness 是围绕模型构建的执行与治理系统。它把模型输出转化为受约束、可追踪、可持续推进的工作过程。

例如，“修复一个测试失败”通常包含：读取报错、定位代码、修改文件、运行测试、根据结果继续调整。模型负责提出行动；Harness 负责提供上下文、调度工具、检查权限、保存结果，以及处理中断和失败。

1.2 Prompt、Context 与 Harness 的关系

三者是相互包含和配合的工程层次，不必理解成严格的历史替代关系。优秀的 Harness 仍然需要良好的提示词和上下文设计。

1.3 一套 Harness 的共同骨架

入口层统一不同渠道的输入；运行时驱动模型和工具；状态与上下文层保存并选择信息；策略层约束外部动作。

图 01 · 入口、模型、工具与状态由运行时协调；权限策略位于动作执行路径。

这些是职责划分。具体项目可以将它们组织成类、crate、服务或插件。

02 · 从一次输入到一个完整任务

2.1 统一基本术语

例如，一次“修复测试”的 Turn 可以包含三个 Step：第一次读取代码，第二次修改并测试，第三次给出结果。每个 Step 又可能产生文本、工具调用和工具结果等多个 Item。

这是一套比较用的词汇，不代表三个项目内部都有相同的Step类型。配置、工作目录、审批策略等属于请求或运行上下文，具体存放在哪一级要看实现。

2.2 Agent loop：关键在反馈闭环

图 02 · 工具结果回到模型形成下一步；没有待处理工作时结束本轮。

一轮工作的基本顺序是：

1. 领取输入，恢复必要状态。
2. 装配指令、历史、相关记忆和工具定义。
3. 调用模型，解析文本与工具调用。
4. 若需要工具，经过策略检查后执行，并记录结果。
5. 将结果提供给模型，继续下一步。
6. 没有待处理工作且满足停止条件时，结束本轮。

“模型没有调用工具”通常是重要的结束信号，但不总是唯一条件。新到达的输入、目标继续策略或生命周期扩展点都可能使工作继续；取消、预算耗尽和不可恢复错误也可能提前结束。

2.3 四种限制，不要混用

例：一个 Turn 有 3 个 Step，其中第一个 Step 请求失败一次、重试成功，则底层模型请求尝试共 4 次。请求尝试数、Step 数和 Turn 数是三个不同指标。

2.4 PTC：用代码组织一组工具调用

PTC（Programmatic Tool Calling）让模型生成一段代码，在受控执行环境中编排工具。代码可以表达串行依赖、并行调用、分支、循环、结果过滤和聚合，再把必要结果返回模型。

例如，查询三个独立数据源可以并行执行；汇总步骤等待三者完成；只有统计结果进入下一次模型请求。这有助于减少模型与工具之间的往返，以及无关结果占用的上下文。

PTC 并不自动赋予更高权限。工具调用仍应经过各自的授权与执行策略，代码运行环境也需要明确边界。

03 · 上下文、状态、记忆与安全

3.1 保存过的信息，不一定都要发给模型

缓存命中与记住用户不是一回事。Prompt 缓存通常复用相同输入前缀的计算，不意味着跳过模型推理；Agent 实例缓存用于减少初始化，也不能代替持久化会话。

3.2 上下文压缩是一种有损的信息选择

图 03 · 会话负责记录，压缩负责当前窗口，记忆与技能服务后续任务。

压缩的目标，是用更少 token 保留继续任务所需的信息，例如当前目标、关键结论、已经完成的动作、未完成事项和必要引用。原始事件可以继续留在持久化层，供检索、审计和恢复。

常见触发位置包括请求前预检、工具结果回填后，以及模型窗口或请求条件变化时。具体系统还可能支持溢出恢复、手动压缩或长会话维护。

压缩需要关注两类风险：一是摘要遗漏关键约束，二是将暂时性判断固化为事实。恢复任务时，应保留可返回原始证据的路径。

3.3 审批、沙箱与指令分别约束不同层面

审批决定某个动作是否获得授权；沙箱限制进程在操作系统或远程环境里能做什么；指令告诉模型应遵循哪些工作原则。

三者需要配合。把规则写进AGENTS.md不等于操作系统会强制执行；用户批准了动作，也不意味着可以越过当前执行环境的限制。Hook 能否阻止动作，则取决于它接入的事件和执行契约。

可靠执行的检查重点是：所有会产生副作用的路径，是否都经过预期的策略与权限控制。工具回调、远程执行和第三方插件也在这个范围内。

04 · Hermes：以长期助手为中心

4.1 架构重心

Hermes 以 Python 为核心，将多入口、会话、工具、记忆、技能和自动化工作流组织到一个长期使用的助手中。其“自我改进”主要指更新外部记忆、技能和工作方法，不代表使用过程中自动训练模型权重。

图 04 · 多入口共用运行时，Profile 为配置、会话、记忆与技能提供持久归属。

所核对的源码版本中，run_agent.py仍是重要入口，但主循环已抽到agent/conversation_loop.py。理解执行过程时，应沿转发关系继续读到真实循环。conversation loop 源码

4.2 Gateway：入口统一与会话路由

Gateway 启动平台适配器，将不同平台消息转换为内部事件，定位会话后交给 Agent，再把结果发回对应入口。

所核对的源码中，Agent 实例缓存的默认常量为128 个实例、空闲 1 小时淘汰，并支持配置覆盖。这是运行中对象的复用策略；它既不是最多只能保存 128 个会话，也不意味着跨平台身份和会话天然合并。Gateway 实现

4.3 Profile、工作区、沙箱与 Bot

典型的 Profile 内容可以按用途理解：

profile 目录 ├── config.yaml / .env 运行配置与凭据 ├── SOUL.md 人格、风格与工作原则 ├── memories/ 长期记忆与用户资料 ├── skills/ / plugins/ 可复用工作流与扩展 ├── sessions/ / state.db 会话及持久状态 ├── cron/ / plans/ 定时任务与计划 └── logs/ / workspace/ 日志及相关工作文件

这是用途示意，实际目录会随版本、配置与使用过程变化。SOUL.md面向助手自身的长期风格；项目里的AGENTS.md面向具体仓库的工作约束。

Bot Mode 在 Profile 管理之上增加角色展示、固定聊天和协作能力。协作可能经本机 Gateway、远程 peer 或桌面 relay 路径发生，需要相应配置，不能由“Profile 相互独立”直接推出“它们自动互通”。

4.4 循环预算与上下文管理

Hermes 具有迭代控制机制，但“主 Agent 默认 500、子 Agent 默认 45”这类数字不宜当作跨版本稳定事实。所核对版本的构造函数和配置归一化已经支持默认无限迭代，而部分预算模块注释仍保留旧默认值。阅读时应核对配置默认值 → 入口传参 → 实际循环条件，不要只依据注释。配置归一化

上下文管理通过可替换引擎组织。需要分别检查的触发场景包括：新轮次预检、工具循环中的检查、请求溢出恢复、恢复闲置会话时的压缩，以及 Gateway 长会话维护。这些路径的开关和阈值可能不同，应分别核对。不同路径的 Token 比例阈值与消息数量阈值不应合并为一个统一规则。

4.5 长期使用的价值与代价

Hermes 的价值在于把记忆、历史检索、技能提炼和消息入口形成连续体验。相应的工程代价是长期状态管理：哪些信息可以复用、何时失效、哪个 Profile 拥有数据，以及切换执行后端后哪些能力仍能工作。

05 · Codex：以执行内核与协议为中心

5.1 分层职责

Codex 的核心实现主要使用 Rust。理解它时，重点应放在运行时与客户端的边界，而不是语言或配置格式本身。

图 05 · 客户端通过协议管理任务，核心运行时协调模型、执行策略和持久化。

模型给出行动意图，内核负责把行动放入可管理的生命周期。App Server 使客户端能够复用这套执行能力；SDK、CLI 和 App Server 的接口形态与适用范围仍应分别看待。

5.2 一轮执行与事件

运行时装配模型输入，消费流式响应，分发工具调用，再把结果反馈给模型。客户端接收事件来更新界面、展示文件变化或参与审批。

事件驱动描述的是推进机制，不代表存在固定的最大 Step 数。结束由模型输出、待处理工作、取消和资源策略共同决定。单轮执行实现

持久化历史为恢复与分叉提供基线，但不能直接等同于外部世界的回滚。重新运行命令可能产生新的副作用；重放历史也不能保证模型输出完全一致。

5.3 Prompt 缓存与压缩

保持稳定的指令和工具定义前缀、把新增内容放在后部，有利于前缀缓存复用。缓存是否命中仍取决于实际请求结构、模型与服务端策略。

Codex 的上下文管理需要区分不同压缩实现。不能把所有压缩都概括成“使用更小编码模型生成加密摘要，因此更保护隐私”。官方 Responses compaction 文档确认，特定压缩路径会返回不透明的加密 compaction item，用于以更少 token 携带此前状态；这并不能推出使用了哪个大小的模型，也不是对整体隐私效果的证明。官方压缩说明

所核对版本的代码包含请求前压缩、运行中压缩及模型切换相关处理。阈值应结合模型元数据和显式配置理解，95% 这类默认比例不宜写成所有模型与路径都适用的常量。压缩调用入口

5.4 配置、指令与扩展分别放在哪里

普通定制通常从这些入口开始。只有需要改变调度、协议或核心状态语义时，才进入运行时内部修改。

官方当前文档给出的普通配置优先级，由高到低为：CLI 覆盖、受信任项目配置、选定的 Profile 文件、用户配置、云端管理默认配置、系统配置、内置默认值。管理要求属于另一层约束，不能简单被项目配置覆盖；配置层级与指令层级也不是同一种机制。官方配置说明

5.5 Profile 与 Agent Role

Codex 的配置 Profile 主要表示可切换的运行参数集合；Hermes Profile 更接近独立助手的持久状态目录。两者名称相同，职责不同。

Agent Role 用于表达特定执行者的指令与受支持配置，例如模型、推理强度和角色说明。它与会话、记忆、工作区仍是不同维度，不能用“一个 Role 就是一个完整独立助手”替代这些概念。

SOUL.md中的内容，在 Codex 中可以按用途分散到全局指令、角色指令、沟通风格、项目规则和技能。这个关系是功能上的近似映射，不是可逐项互换的配置转换表。

5.6 Hooks 与长期记忆

Hook 由运行时生命周期事件与匹配规则触发，不依赖模型主动选择调用。不同 Hook 可以观察、补充或阻止不同环节；并非每个 Hook 都能任意修改所有状态，也不能把 Hooks 与命令 Rules 当成同一机制。

所核对的 Codex 源码 已有两阶段记忆流程：先从符合条件的历史 rollout 提取记忆，再整合成可复用材料。运行受开关、会话类型、状态数据库等条件限制，后台还需要任务认领、并发控制和失败退避。有实现不代表所有客户端都默认启用。记忆流水线说明

06 · DeepSeek Harness：以可组合运行时为中心

6.1 Cordis 提供服务与生命周期组织

DeepSeek Harness 以 TypeScript 和 Cordis 组织插件。插件可以向上下文注册服务、工具或事件监听器，消费者通过声明的依赖和接口使用它们；插件卸载时，相关注册副作用随生命周期清理。

这里的解耦主要指通过服务接口连接运行时组件，不表示 TypeScript 模块之间完全不需要import。

6.2 Plugin、Bundle 与 Profile

Bundle 的价值是封装重复接线、依赖与默认配置。它可以只包含一个插件，也可以没有自己的运行时代码；是否“多个插件”不是判定 Bundle 的关键。

图 06 · Profile 按顺序叠加配置层，Cordis 启动最终插件树；循环算法仍由插件代码实现。

启动时，从空配置树开始，按顺序应用：

1. Profile 中列出的各个 Bundle Patch。
2. Profile 自身的cordis.patch.yml。
3. Home 级cordis.patch.yml。
4. 命令行指定的 Patch，按出现顺序叠加。

后层可以针对已有行进行覆盖或插入新行。不能把这种操作想当然地理解成所有字段都会递归深合并；架构文档明确提到按 id 替换整份 config 的行为。架构说明

例如，“企业代码搜索”可以由认证、搜索服务、模型工具三个 Plugin 实现，再通过一个企业 Bundle 安装和接线。Web Profile 将基础 Bundle、Web Bundle 和企业 Bundle 组合成可启动环境。

6.3 装配决定使用谁，代码决定怎样运行

可替换 loop 不等于用 YAML 逐节点拼出循环算法。YAML 选择并配置插件；默认 loop 内部仍是一套明确的 TypeScript 实现。

6.4 Turn / Step 与 Inbox

默认 driver 在 Turn 开始时领取 next-step 输入和一条 next-turn 消息；Step 之间处理新到达的 next-step 输入。followup()、steer()、inject()的队列和唤醒语义由实现定义。

每个 Step 装配提示词和工具定义，从 Session 日志派生模型历史，调用模型，执行工具并写回结果。若工具结果仍需模型处理，或者收到新的即时输入，就继续下一步；结束前还会经过生命周期扩展点。

一个 Turn 可以包含零个 Step，例如首批输入在进入模型请求前被拒绝或改写为空。该尝试仍然可以留下 Turn 生命周期记录。Turn flow

6.5 工具调度与循环上限

默认实现区分可并行工具和独占工具，并处理取消后的结果收敛。maxParallelToolCalls控制并发，不控制循环次数；maxTokens控制输出，不控制 Step 总数。

所分析版本的默认 Agent loop 没有通用的固定最大迭代数字段。若部署需要限制 Step、时间或总预算，应在实际可用的生命周期扩展点执行策略，并测试超限后是否停止新调用、保存结束原因、收敛已启动任务。

仅在“准备结束”事件里检查预算可能太晚：如果工具循环一直继续，就未必走到那个事件。具体接入点要依据真实事件签名和调用时机，概念伪代码不应直接当作可运行插件。

6.6 日志作为模型上下文的依据

Session 使用追加式事件记录；deriveMessages()从日志派生模型历史。运行时不变量检查用于核对请求信息与记录的一致性。

这种设计方便回答“模型当时看到了什么”。压缩后的可见历史可以从事件中派生，原始历史仍具有追溯价值。但重建输入不等于确定性重现模型输出，也不等于重新执行工具会得到相同结果。请求重建校验

6.7 Capability seam：把接口与执行环境拆开

一个完整的能力替换边界包含三种角色：Service Definition 定义契约，Service Provider 提供实现，Consumer 使用能力，模型工具通常属于消费者之一。

以 Shell 为例，模型看到 Bash 工具，工具消费子进程执行服务，服务提供者再决定操作发生在本机还是远程执行环境。替换提供者，可以让多个消费者共同切换到新的执行环境。

Capability 是内部能力抽象，Tool 是面向模型的调用接口。二者可能是一对多或多对一，不能简单断言所有 capability 的粒度都比工具更小。

07 · 三种设计，放在同一张表里看

7.1 设计重心与工程代价

这是一张架构比较表，不是能力评分表。某个系统更强调一种能力，不意味着其他系统没有该能力。

7.2 三种 Profile 不应直接画等号

7.3 并行、多 Agent 与调度是三层能力

并行工具调用是一个 Agent 同时执行多个独立操作；多 Agent 是多个上下文之间的分工与通信；持久调度是按时间或条件唤醒任务，并在重启后保持计划。

Hermes 将 cron 与网关投递连在一起；Codex 的内核任务生命周期需要与 App 或宿主调度分开看；DeepSeek Harness 将子代理、后台任务和调度拆成模块。固定间隔调度也不等于完整日历 cron 语义。DeepSeek 调度说明

7.4 安全能力要检查实际路径

DeepSeek Harness 的沙箱文档区分full与partialenforcement，并限定相关 SandboxMode 的文件系统策略范围；不要从名称推导网络或进程隔离承诺。沙箱说明

Codex 将审批与沙箱尝试组织在工具执行路径中；具体保护仍取决于平台、配置和使用的工具。工具编排器

Hermes 的入口授权、命令审批、文件保护和执行后端承担不同职责。local 后端与容器后端的边界不同。安全模型

08 · Harness 可以组合，但职责必须清楚

8.1 Hermes 使用模型与委托运行时是两回事

图 07 · 两条路径的区别是执行循环的归属；组合运行时还要明确状态与权限边界。

路径 A：Hermes 调用 OpenAI 模型。模型由 OpenAI 提供，但循环、工具调度和上下文推进仍由 Hermes 管理。

路径 B：Hermes 委托 Codex App Server。Hermes 负责外围入口和相关工作流，Codex 承担模型与工具循环；部分 Hermes 工具通过 MCP 回调接入。

Hermes 的对应版本文档将后者标为可选运行路径。它还明确指出，依赖活动AIAgent状态的delegate_task、memory、session_search、todo不能通过无状态 MCP 回调直接提供；外围记忆与技能 review 有另外的处理路径。因此，组合后的能力不是两张功能表的简单相加。运行时集成说明

8.2 组合前需要明确的四个归属

这四个问题比“API 是否能调用成功”更能说明集成是否完整。

参考资料与版本范围

本文核对了与架构主线相关的关键实现，没有逐行审计全部项目，也未运行三套系统的行为测试。

以上为核对时的源码版本，不代表最新发布版本。源码链接固定到对应提交，便于复查；部分特性仍受产品版本、配置与宿主支持限制。

外部补充仅使用官方资料：Codex 配置、Responses Compaction。资料核对日期为 2026-10-03。