从Transformer到Agent---Agent知识（一）

从 Transformer 到生产级 Agent：基础知识了解

一提到 AI，就会听到一大堆名词：Transformer、GPT、LLM、Prompt、CoT、RAG、Memory、MCP、Skill、ReAct、Plan-and-Execute、Reflection、Evals、Multi-Agent、Context Engineering、Harness Engineering、Agent......搞得人一头雾水。它们来自不同阶段、解决不同问题，却经常被放在一起讲，容易误以为它们是互相替代的产品或框架。其实不然，这些名词的出现不是严格的历史时间线，而是许多能力并行发展，成熟系统通常会同时使用其中多项。

1. 为什么学Agent要了解这些

写本文的目的，是在开始学习具体工具和实现之前，先弄清楚这些概念是为什么出现、在系统的哪一层、为前一阶段补上了什么能力。这样再接触某个框架或产品时，就能判断它究竟是在增强模型、补充知识、连接工具，还是在管理整个 Agent 的运行过程。

2. 一句话建立全局认识：每一步都在增强之前的能力

AI的发展不是 "模型越来越会聊天"这么简单，而是不断回答一个问题：它能回答，但能否听懂我的意图？知识会过时怎么办？能否读取我的业务资料？能否替我操作系统？操作错了谁来检查和兜底？

上一阶段的短板	因而增加的能力	解决后的典型应用
长文本关联和并行训练上的瓶颈	Transformer 用注意力机制让词彼此直接建立关联，并可大规模并行训练；在此基础上出现 GPT 路线和 LLM	翻译、摘要、生成文本、代码补全
模型会续写，但不一定按人类要求交流	指令微调、对齐、聊天界面	ChatGPT、DeepSeek 等通用对话助手
同一句模型可能答得不稳定、不符合格式	Prompt Engineering（提示词工程）与结构化输出	文案助手、问答机器人、信息抽取、固定格式报告
模型参数中的知识有训练截止时间，也没有企业私有资料	知识工程、RAG（Retrieval-Augmented Generation，检索增强生成）与上下文工程	企业知识库问答、制度查询、客服辅助、投研/法务检索
模型只能"说"，不能真正"做"	工具调用、MCP（Model Context Protocol，模型上下文协议）、Skills（技能）	查订单、查数据库、发消息、运行代码、生成文件
一次调用无法完成多步骤任务	ReAct（Reasoning and Acting，推理与行动）、规划执行、记忆与反思	研究助手、数据分析助手、编码助手、工作流自动化
单个 Agent 处理复杂任务慢且易丢失重点	多 Agent 协作	研究分工、代码开发/测试/审查分工、复杂运营流程
自动执行带来安全、成本、错误恢复和合规风险	Harness Engineering（Harness 工程）、权限、评测、审计、人工接管	可在生产环境运行的客服、运维、编码和业务 Agent

可以把它们类比为：

LLM 是员工的思考能力；
Chatbot（对话机器人）是把员工放到聊天窗口服务用户；
RAG 是查资料；上下文工程是每次递交的任务包；
Agent 是能自己推进工作的员工；
Harness 则是办公环境、工具、流程、质检和交接制度。

Transformer 为什么会发展出 GPT / LLM？GPT 和 LLM 是一个概念吗？

Transformer 出现前，主流文本模型常用 RNN 和 LSTM：它们阅读"我今天去银行办理业务"时，通常要按顺序一个词一个词处理。文本变长后，早先信息难以有效影响后面的判断，同时训练也难以充分并行，成本很高。

Transformer 的注意力机制允许模型在处理一个词时，直接关注句子中的其他相关词；例如处理"办理"时可以直接关联"银行"和"业务"。这一架构非常适合 GPU（Graphics Processing Unit，图形处理器）并行计算，因此可以用海量语料、更多参数和更长训练时间来扩大模型能力。Transformer 提供了可规模化的"发动机"；GPT 和各类 LLM 则是基于这台发动机训练出来的模型路线和模型产品。

GPT 和 LLM 不是同义词：

概念	它指什么	关系
Transformer	一种神经网络架构	是现代主流 LLM 的技术基础
GPT（Generative Pre-trained Transformer，生成式预训练 Transformer）	基于 Transformer 的一条具体生成式预训练路线；典型方式是根据前文预测下一个词或 Token（词元）	GPT 模型通常属于 LLM
LLM（Large Language Model，大语言模型）	对大规模语言模型的统称，强调规模、通用语言能力和训练方式，不是某个单一产品名	LLM 可以采用 GPT 式架构，也可以采用其他 Transformer 变体

因此应理解为：Transformer → 可扩展的预训练模型 → GPT 等具体路线 / 各类 LLM。GPT 是 LLM 家族中的一类重要成员；并非所有 LLM 都是 GPT。

3. 能力叠加流程图

flowchart TD transformer["1. Transformer 解决 RNN/LSTM 难并行、难捕获长距离关联"] llm["2. GPT / 预训练语言模型 → LLM 利用 Transformer 进行大规模预训练"] align["3. 指令微调与对齐 可对话、可遵循要求"] chatbot["4. Chatbot（对话机器人） ChatGPT、DeepSeek 等对话产品"] prompt["5. 提示词与结构化输出"] cot["6. CoT（Chain-of-Thought，思维链）：分步推理"] context["7. 知识与上下文 RAG、记忆、任务状态"] tools["8. 工具调用（MCP/Skills） 查询、写库、发消息、运行代码"] react["9. ReAct 推理 → 行动 → 观察 → 再推理"] agent["10. 单 Agent（智能体） 围绕目标自主选择工具并循环推进"] plan["11. Plan-and-Execute 规划 → 执行 → 异常重规划"] reflect["12. Reflection 与 Evals（Evaluations，评测） 检查、修正与系统评估"] multi["13. 多 Agent 分工、委派、交接、汇总"] prod["14. 生产级 Agent 权限、审批、审计、监控、人工接管"] transformer --> llm --> align --> chatbot --> prompt --> cot --> context --> tools --> react --> agent --> plan --> reflect --> multi --> prod prompt -. "产生" .-> prompt_eng["Prompt Engineering 提示词工程"] context -. "包含" .-> knowledge_eng["知识工程 / RAG 工程 / 上下文工程"] tools -. "通过" .-> tool_layer["Function Calling / MCP / Skills"] chatbot -. "可扩展" .-> multimodal["多模态 图片、语音、文档等输入输出"] agent -. "开始需要" .-> harness["Harness 工程 贯穿 Agent 的运行、验证、恢复与治理"] plan -. "强化" .-> harness reflect -. "强化" .-> harness multi -. "强化" .-> harness prod -. "生产化" .-> harness

图中的主线表示能力的逐层叠加；右侧分支表示相应阶段发展出的工程实践。Chatbot 是面向用户的产品形态，而不是一个新的模型架构；同一个 Chatbot 后续可逐步接入搜索、文件、知识库和工具，从"能聊天"演进为"能完成任务"。Harness 工程从 Agent 开始调用工具、进入循环时就出现，并在长任务和生产部署时变得关键。

4. 各阶段到底增加了什么

阶段	解决的问题 / 新增能力	常见应用	仍然缺少什么
Transformer / GPT / LLM	阅读、写作、归纳、生成、一定程度的推理	翻译、摘要、写作、代码补全	不理解用户的隐含意图，知识会过时，不能操作外部系统
指令微调、对齐与 Chatbot	把"会续写"变成"会按要求对话"	ChatGPT、DeepSeek 等通用对话助手	只依赖模型参数和当前对话，无法天然获得外部/企业实时资料
提示词工程	将角色、目标、约束、示例和格式表达得更明确	文案助手、结构化信息抽取、报告初稿	长任务状态、自动执行能力
CoT	将复杂推理拆为步骤，提高可检查性	数学/逻辑辅助、复杂问答、方案比较	真实世界反馈和行动能力
RAG、记忆、上下文	使用私有/最新资料，保留任务状态	企业知识库问答、制度查询、客服辅助、资料检索	不能天然执行外部操作
工具调用	查询系统、改文件、运行代码、调用业务接口	查订单、数据分析、代码助手、自动生成文件	不一定会自主选择和连续使用工具
ReAct	建立"推理---行动---观察"的循环模式	搜索型助手、代码调试助手、简单自动化流程	还缺目标持续性、任务状态和系统治理
单 Agent / 规划执行	围绕目标自主选择工具、保持状态并根据反馈推进	研究 Agent、编码 Agent、跨系统流程自动化	长时程稳定性、错误恢复、治理
Reflection / Evals	自我修正和系统性质量验证	自动测试修复、答案质量检查、回归测试	可扩展协作与生产运行保障
多 Agent	并行探索、专业分工、上下文隔离	多角色研究、开发/测试/审查协作	协调成本、权限边界和全局一致性
生产级 Agent	可控、可审计、可运营地交付任务	生产客服、运维处置、企业流程、长期编码任务	仍需持续评测和人工监督

同一个产品可以跨越多个阶段

ChatGPT、DeepSeek 等是面向用户的产品形态，而不是某个固定技术阶段。一个对话产品可以在基础聊天能力之上，逐步接入检索、文件、工具和 Agent 循环，从"能聊天"发展为"能完成任务"。

以 ChatGPT 等产品常见的功能演进为例：

用户看到的功能	实际叠加的能力	它解决的问题
聊天、写作、翻译、总结	LLM + 指令对齐 + 聊天界面	让模型能以自然语言协助工作
更稳定的角色、格式和语气	提示词工程、结构化输出	让结果可复用、可接入后续系统
搜索网页、读取上传文件、连接企业资料	RAG / 检索 / 上下文工程	模型训练后的新信息，以及企业内部知识，不在模型参数中
分析表格、运行代码、生成文件、发送消息	工具调用	从"给建议"变成"执行操作"
为一个目标连续查找、分析、执行和验证	Agent 循环 + Harness	从一次问答变成多步骤任务交付

**"获取训练截止日期之后的信息"并不等于模型重新学习了新知识。**通常是搜索、文件连接器或 RAG 在回答时检索到新资料，再将资料放进当前上下文供模型阅读。企业场景中，RAG 正是为了解决"模型天然看不到内部系统、制度文档、私有数据库和最新数据"这一问题。

5. 提示词工程：Chatbot 为什么还需要 Prompt？

有了 Chatbot 后，用户会发现一个新问题：**模型能回答，不代表每次都能按所需的角色、范围、口吻和格式回答。**例如，直接问"分析这份销售数据"，得到的结果可能过于笼统；但若明确说明数据范围、指标定义、受众、输出结构和禁止臆测的要求，结果会稳定得多。

**Prompt（提示词）**是交给模型的任务说明；**Prompt Engineering（提示词工程）**是系统化设计、测试和维护这些说明的工作。它常包括：

角色与任务目标：例如"你是一名财务分析助手"。
约束与边界：例如"仅依据提供的数据；不确定时明确说明"。
示例与术语：例如提供正确答案范例和业务字段定义。
输出约定：例如固定 Markdown 标题、JSON（JavaScript Object Notation，对象表示法）或表格字段。

它解决的是"怎样让一次模型调用更符合预期"，而不是补充模型不知道的事实，也不是让模型真的执行操作。因此提示词工程之后，仍会自然发展出 RAG、工具调用和 Agent。

6. "知识与上下文"分别是什么工程？

它不是单一工程名词，而是为解决"模型看不到最新资料和企业内部数据"而出现的三个相互嵌套层次。

工程	主要问题	典型工作
知识工程	企业知识是否正确、完整、可理解、可授权使用？	文档治理、数据清洗、元数据、知识图谱、版本和访问权限
RAG 工程	如何从知识中找出最适合当前问题的证据？	文档切分、向量化、混合检索、重排序、引用、召回率与准确率评测
上下文工程	这一轮推理究竟把哪些信息交给模型？	系统指令、检索片段、对话摘要、记忆、工具说明、任务状态的选择与压缩

关系可以写成：

text 复制代码

知识工程：建设和治理"知识库"
  ↓
RAG 工程：从知识库取回当前问题的"证据"
  ↓
上下文工程：把证据连同任务、规则、状态等，组成当前这一轮的"最小有效上下文"
  ↓
LLM / Agent：据此推理或行动

因此，RAG 是上下文工程的重要输入方式，但上下文工程不等于 RAG。即使没有知识库，如何控制历史对话、文件、执行结果和工具说明，也仍然是上下文工程。

7. 工具调用：MCP 还是 Skill？

RAG 能让模型"看见"资料，但它仍然只能给建议：它不能查询订单的实时状态、提交审批、写入数据库或运行测试。工具调用就是为解决"模型只能说、不能做"而出现的能力；MCP 和 Skill 都不是工具调用本身，而是工具层的不同组成部分。

名称	它是什么	与工具调用的关系
工具调用	Agent 请求执行外部能力的行为，例如 `查询订单`、`运行测试`	核心动作
Function Calling（函数调用）	模型以预定义结构化参数表达工具请求的常用机制	工具调用的一种接口形式
MCP	让 Agent/应用以统一方式发现、连接和调用外部工具与资源的协议	类似标准化"接口和接线规范"
Skill	让 Agent 完成某类任务的可复用操作说明和资源包	类似"岗位操作手册"；可指导工具选择，也可附带脚本、资料、规则
API（Application Programming Interface，应用程序编程接口）	具体业务系统暴露出来的能力	通常是工具最终调用的服务接口

一个典型的调用关系如下：

flowchart LR skill["Skill 告诉 Agent 如何完成 例如：发布版本"] agent["Agent 理解目标并选择下一步"] function["Function Calling 形成结构化工具请求"] tool["工具 例如：部署工具"] api["业务 API 执行部署、查询或写入"] result["执行结果 状态、日志或数据"] mcp["MCP 标准化发现、连接和暴露工具"] skill --> agent --> function --> tool --> api --> result --> agent mcp -. "可用于连接 / 发现" .-> tool

也就是说，Skill 主要告诉 Agent "该怎么做"；MCP 主要解决"怎么以标准方式连接和发现工具"；Function Calling 主要解决"怎样发出结构化请求"；真正的工具再调用业务 API 执行操作，并把结果返回给 Agent 继续判断。并非每次调用都必须经过 MCP，Agent 也可以直接集成工具接口。

8. "反思与评估"就是 Reflection 吗？

反思通常指 Reflection，但"反思与评估"包含两个不同层级：

Reflection（反思）：任务执行过程中的内部闭环。例如 Agent 运行测试失败后读取错误日志、找出原因、修改代码并再次验证。这是"这一次任务如何修正"。
Evaluation / Evals（评估）：系统级的外部度量。例如用一组固定客服问题检查答案正确率，用安全测试检查越权率，用线上指标检查任务完成率。这是"这个 Agent 系统是否可靠"，也是测试开发工程师在 AI 时代的重要质量保障工作。

Reflection 能帮助一次任务自我修正，但不能取代独立 Evals。尤其在高风险场景，应优先依赖可验证的工具结果、规则、测试和人工审批，而非只让模型"自我感觉正确"。

9. Evals：测试开发工程师在 AI 时代如何保障 Agent 质量

传统软件测试重点验证"给定输入，程序是否产生确定的正确输出"。Agent 的输出带有概率性，还会检索资料、调用工具、分多步执行，因此仅测接口是否返回 200 或代码是否覆盖，并不能证明任务真的完成、动作是否安全。

Evals 不是让模型替代测试开发工程师，而是把测试开发工程师的能力延伸到 Agent：把模糊的业务要求转成可重复运行、可度量、可拦截回归的质量标准。

传统测试开发关注点	Agent 时代对应工作
接口、页面和业务流程是否正确	最终答案、工具选择、执行轨迹和业务结果是否正确
边界值、异常分支、权限校验	歧义指令、错误检索、提示词注入、越权工具调用、失败重试
测试用例与自动化脚本	评测集、评分器（Grader）、工具模拟、回归门禁和线上抽样
缺陷定位	区分问题来自模型、提示词、RAG、工具、Harness 还是业务数据

从哪里开始：先定义"什么算完成、什么绝不能发生"

不要追求大而全的评分体系。选择一个明确的 Agent 任务，例如"订单退款助手"或"企业制度问答助手"，先回答下面四个问题：

要先明确的内容	例子：订单退款 Agent
任务成功是什么	核验订单、计算正确退款金额、在需要时获得用户确认并完成退款
绝不能发生什么	未核验身份就退款；金额错误；重复退款；泄露其他用户订单信息
什么证据可以验证	工具调用参数、订单状态、退款流水、回复内容、执行日志
上线阈值是什么	所有高风险场景必须 100% 通过；低风险回答允许小范围人工抽样复核

从真实客服记录、线上故障、产品验收案例和业务专家访谈中收集场景，整理为"黄金评测集"。每条案例至少保留：用户输入、可访问的上下文/资料、预期结果、禁止动作和评分规则。不要只收集正常问题；高价值案例往往是歧义、冲突、缺资料、过期资料和越权请求。

如何做：建立持续的评测闭环

flowchart LR req["业务目标与风险"] cases["评测集 正常、边界、失败与安全案例"] run["运行 Agent 记录回答、工具调用与执行轨迹"] grader["评分器 规则、测试、模型裁判、人工抽样"] report["结果报告 通过率、失败类型、成本、耗时"] gate["发布门禁 / 线上监控"] feedback["真实反馈与故障"] req --> cases --> run --> grader --> report --> gate feedback --> cases report --> cases

构建评测集：先做 20--50 条高优先级场景，而不是一开始收集几千条泛泛问题；每次线上事故都应沉淀成一条回归案例。
记录完整轨迹：除最终回答外，还要记录检索到哪些资料、选了什么工具、传了什么参数、工具返回什么结果、重试了几次。
选择合适评分器：能用确定性规则验证的，不用模型主观判断；需要判断语义质量时，再使用模型裁判并做人类校准。
接入发布门禁：提示词、模型版本、RAG 索引、工具定义或 Harness 改动后，自动运行离线评测；高风险失败则阻止发布。
线上持续评测：抽样复核真实会话，监控任务完成率、人工接管率、越权拦截率、工具失败率、延迟与成本；将新失败回流到评测集。

测什么：不能只测最终回答

评测层	要验证什么	推荐验证方式
输出契约	JSON、字段、格式、必填信息、禁止承诺	Schema（数据结构约束）、字符串/规则检查
事实与 RAG	是否检索到正确、最新、权限允许的资料；回答是否有依据	文档命中、引用来源、答案事实核对
工具行为	是否选择正确工具、参数正确、失败时不误操作	模拟工具、参数断言、数据库状态比对
执行轨迹	是否在合理步骤内完成；是否循环、遗漏确认或错误重试	轨迹断言、步骤上限、状态机测试
安全与权限	是否抵抗提示词注入、数据泄露、越权和危险操作	对抗用例、最小权限测试、审批/拒绝断言
体验与运营	是否完成任务，是否过慢、过贵、频繁转人工	线上指标、用户评分、人工抽样

评分器怎么选

确定性评分器优先：例如 JSON 是否符合 Schema、是否调用了错误工具、退款金额是否等于订单金额、数据库是否只有一条退款记录。这类规则最可靠。
程序化评分器：通过测试代码、数据库查询、接口断言验证业务结果，适合工具调用与工作流结果。
模型裁判（LLM-as-a-Judge，用大语言模型充当裁判）：用于"回复是否清晰、是否覆盖关键点、引用是否充分"等难以硬编码的语义判断。必须给出明确评分量表，并用人工标注样本核验它与业务标准是否一致。
人工抽样：高风险、低频、模糊或评分器分歧的案例，应由业务专家或测试人员复核；人工结论再回流为更好的评测集和规则。

一个可执行的起步计划

时间	测试开发工程师可以完成的工作
第 1 周	选择一个 Agent 场景，绘制流程与权限边界，列出 20 条高风险用例和验收标准
第 2 周	建立黄金评测集，补齐工具模拟、关键业务状态断言和失败分类
第 3 周	将离线 Evals 接入 Continuous Integration（持续集成，CI）；为提示词、模型、检索和工具改动设置回归门禁
第 4 周及以后	建立线上抽样、告警和事故回流机制，持续扩充评测集并优化评分器

测试开发工程师的核心价值会从"发现页面或接口缺陷"扩展为：定义 Agent 的可接受行为边界，并用可验证证据证明它在变化后仍然可靠。

10. Harness 工程在什么阶段出现？

它不是 LLM 的训练方法，而是 Agent 的运行系统

Harness 工程不直接增强 LLM 的参数能力；它围绕 LLM 构建一个能把任务做完的闭环。最简形式从"工具调用 + ReAct"开始就已经存在：系统需要持续调用模型、执行工具、把结果返回给模型。

当任务进入 Plan-and-Execute、Reflection、多 Agent 和跨多个上下文窗口的长任务时，Harness 变成核心能力；在生产级 Agent 中，它是必需的底座。

text 复制代码

                   ┌────────── Harness 工程（贯穿 Agent 生命周期）──────────┐
用户目标 → 任务循环 → 上下文组装 → LLM 决策 → 工具执行 → 结果验证 → 状态持久化
                   │       ↑                │              │             │
                   │  记忆/恢复        权限/沙箱       测试/评测      日志/审计 │
                   └─────────────────────────────────────────────────────┘

              ↑ 上下文工程主要负责"上下文组装"这一环
              ↑ RAG 工程主要负责"检索证据"这一类上下文输入

Harness 工程通常包含什么

任务编排：何时继续、重试、拆分、暂停、恢复或交给人工。
工具与执行环境：工具注册、路由、沙箱、文件系统、网络与凭据隔离。
上下文和状态管理：会话记录、摘要压缩、任务清单、跨会话记忆。
验证反馈：单元测试、浏览器验证、规则检查、结果比对、评测。
安全与治理：最小权限、审批、审计日志、提示词注入防护、预算与速率限制。
工程环境可读性：让 Agent 能找到规范、架构、运行脚本、测试、日志和领域文档。

它与其他方式的区别

概念	关注点	不解决的部分
提示词工程	怎样写好一段指令	工具执行、状态持久化、验证闭环
上下文工程	当前一轮应给模型哪些信息	如何安全执行、重试、审批和运营系统
RAG 工程	如何检索可靠知识	任务推进和外部行动的整体控制
Agent 设计	如何规划、选择工具、完成目标	运行时基础设施和全生命周期治理
Harness 工程	如何把 Agent 放入可执行、可观察、可验证、可恢复的环境	不替代模型能力、知识质量或业务设计

可把它浓缩为：上下文工程管理"模型这一轮看到什么"；Harness 工程管理"整个 Agent 系统如何跨许多轮把事情可靠做完"。

它是什么时候提出的？

"Harness"作为软件测试和运行支撑环境的通用术语早已存在，因此没有一个公认的"首次提出"日期。它在生成式 AI 领域成为明确的工程话题，则是伴随长时程编码 Agent 在 2025 年后快速发展而显著升温的。

Anthropic 在 2025 年 11 月发布长时程 Agent 的 Harness 实践，重点讨论跨多个上下文窗口的持续工作。Effective harnesses for long-running agents
OpenAI 在 2026 年 2 月以 Harness Engineering 总结 Agent-first 软件工程实践：把仓库、工具、测试、评审与反馈回路设计成 Agent 可理解、可验证的工作环境。Harness engineering: leveraging Codex in an agent-first world

这里的日期描述的是该术语在 Agent 工程中的公开传播与实践成熟，而不是说相关技术在此前不存在。

11. Codex 与 DeepSeek Harness：当前组合与实现方式对比

以下比较的是 Harness 的组合方式和运行机制，不是 GPT 与 DeepSeek 模型能力的跑分比较。DeepSeek Harness 仍处于开发者预览阶段，插件和接口仍可能变化。Codex 官方说明与 DeepSeek Harness 官方说明均强调：Agent = 模型 + Harness。

如果要自己做一个 Agent：先按业务组合这些能力

不要把自建 Agent 理解为"选一个模型，再写一段提示词"。应先从业务目标、风险和可验证结果出发，逐项判断下面的能力是否需要、如何组合：

text 复制代码

Transformer / LLM 提供理解、生成与推理能力
↓
提示词工程 + 上下文工程 提供清晰且足量的当轮信息
↓
知识工程 + RAG 工程 提供可靠、可更新、可追溯的外部知识
↓
工具调用 + MCP + Skills 提供可执行的动作和标准化连接
↓
Agent 模式 提供目标导向的决策、规划与循环执行
↓
Reflection + Evals 提供任务内修正与系统级质量控制
↓
Harness 工程 将上述能力组织为可持续运行的生产系统
↓
人工审批与治理 决定哪些动作可以自动执行、何时必须人工接管

例如，企业制度问答通常首先需要"提示词 + 知识工程 + RAG + Evals"，未必需要复杂 Agent；而自动退款、运维处置或编码 Agent 则还需要工具调用、权限审批、Harness 和更严格的回归评测。下面的 Codex 与 DeepSeek Harness 对比，正是两种将这些能力组合起来的实现方式。

先看核心区别

Codex Harness：将 Agent 循环、上下文、工具、沙箱、审批和跨轮状态组织为一套可复用的运行时；通过 Codex App、命令行、软件开发工具包（Software Development Kit，SDK）和 App Server 供用户或应用接入。它更像一套"已有成熟工作方式、可嵌入产品"的 Agent 运行时。
DeepSeek Harness：以 Cordis 内核负责插件装载和依赖关系，模型、工具、Skill、会话、沙箱、存储、循环、调度和用户界面（User Interface，UI）全部作为可替换插件组合。它更强调"从插件拼出自己的 Agent 运行时"。

两者都将模型和 Harness 分开：模型负责思考和生成，Harness 负责让模型获得上下文、调用工具、持续运行并受到约束。不同点主要在于：Codex 偏向提供一套可直接使用、可嵌入的 Agent 循环；DeepSeek Harness 偏向提供一个插件优先、可重组的 Agent 内核。

当前组成方式

维度	Codex Harness	DeepSeek Harness
核心定位	可复用的 Codex Agent 运行时；同一 Harness 支撑 App、命令行和集成场景	面向 Harness 开发者的插件化 Agent 运行时，当前为开发者预览
核心内核	Harness 负责会话状态、执行流、工具、审批和策略；App Server 对外暴露线程、回合和事件	Cordis 内核只管理插件加载、卸载和依赖；具体 Agent 能力由插件提供
模型组合	Codex 产品体验通常使用 Codex / OpenAI 模型服务；开源 Harness 与模型访问、托管服务分层	模型本身是插件之一，可配置、替换或扩展；并不被单一模型绑定
上下文与状态	以任务线程和回合维护对话状态；Harness 组织上下文、跨轮推进和恢复	以追加式会话日志记录提示词、推理、工具结果、子 Agent 调度和上下文注入；可在同一事件流上恢复、分叉、搜索和回放
工具与扩展	通过本地/云端环境、MCP、Skills、子 Agent、Hooks 与应用自有工具扩展	工具、Skills、沙箱、存储、循环、调度、UI 都是插件，可在配置中替换或重组
执行与安全	使用配置的沙箱与审批策略；主机/应用可决定可访问的文件、工具，以及哪些操作要批准	提供沙箱等能力插件；实际权限、审批和隔离边界取决于选用的插件与配置，需要开发者组合并验证
可观察性	可流式获取执行事件、处理审批请求，并由宿主应用呈现任务进度和结果	重点强调全量轨迹：每次运行写入追加式日志，可按来源检查和回放
典型运行形态	App、命令行、集成开发环境、脚本/持续集成任务、SDK/App Server 嵌入业务应用	Standard、Code、Minimal、Creator 四种模式；尤其适合试验不同插件和自定义预设

具体怎么理解"实现方式"的差异

需求	更接近 Codex 的实现思路	更接近 DeepSeek Harness 的实现思路
新增企业工具	将工具或 MCP 服务接入既有 Codex 工作流，并在 Skill / 仓库说明中交代使用规则	编写或选用工具插件，再由 Cordis 配置把它装入某个运行模式
给 Agent 增加领域规范	在 `AGENTS.md`、Skills、仓库文档和任务提示中提供分层、可发现的上下文	通过 Skill、会话或上下文相关插件组合领域规则和资源
改变工具权限	调整沙箱、审批和宿主应用策略，明确哪些动作须人工批准	替换/配置对应的沙箱、工具、会话插件，并自行验证权限与审批闭环
调试一次失败任务	从线程事件、工具输出、工作区变更和测试结果回溯	从追加式 Session Log 和 Trajectory 查看每次上下文注入、推理、工具调用与调度事件
试验不同 Agent 形态	在同一 Harness 内通过工具、Skills、MCP、子 Agent 与环境配置逐步扩展	在 Standard / Code / Minimal / Creator 模式间切换，或重组插件来生成新的预设

应如何选择理解路径

如果目标是尽快在软件工程或业务流程中部署一个可用 Agent，先理解 Codex 的"任务线程 + 工具环境 + 审批/沙箱 + 可验证反馈"组合，会更直观。
如果目标是研究或开发可替换底层组件的 Agent 平台，DeepSeek Harness 的"Cordis 内核 + 一切皆插件 + 统一事件日志"更能体现 Harness 的可组合性。
两者都不能省略第 9 部分的 Evals。Harness 决定 Agent 如何运行；Evals 决定它是否足够可靠。无论选哪一种，权限、业务工具断言、回归评测和线上监控仍要由团队建立。