从提示词、检索增强生成、工单与技能，到运行支撑与闭环：一文看懂 AI 智能体工程

前言

很多人第一次接触人工智能智能体（AI Agent），首先关注的是提示词怎么写、模型怎么选、上下文窗口有多长。

但当智能体开始读取代码仓库、搜索资料、调用工具、修改文件、执行测试，甚至持续工作数小时以后，问题就发生了变化。

此时最重要的已经不只是：

怎样让大语言模型（Large Language Model，LLM）生成一次更好的回答？

而是：

怎样让一个由模型驱动的软件系统，持续、可靠、可验证地完成真实任务？

围绕这个问题，逐渐形成了一组相互关联的知识点：

• 提示词工程（Prompt Engineering）；
• 检索增强生成（Retrieval-Augmented Generation，RAG）；
• 上下文工程（Context Engineering）；
• 规格工程（Specification Engineering）；
• 工单工程（Ticket Engineering）；
• 技能工程（Skill Engineering）；
• 工具接口工程（Tool Engineering）；
• 智能体运行支撑工程（Harness Engineering）；
• 智能体闭环工程（Loop Engineering）；
• 多智能体编排（Multi-Agent Orchestration）；
• 记忆与状态工程（Memory and State Engineering）；
• 智能体评测（Agent Evaluation）；
• 可观测性（Observability）；
• 人机协同（Human-in-the-Loop，HITL）。

这些概念并不都是最近才出现的。

信息检索、上下文选择、状态管理、工作流、任务队列、反馈控制、自动化测试等技术早已存在。近年的主要变化，是它们开始围绕大语言模型和智能体重新组合，形成更完整的智能体工程体系。

---

一、先用一张关系图看懂整个体系

可以先记住下面这组关系：

用户提出目标
    ↓
规格明确“最终要实现什么”
    ↓
工单规定“本次具体交付什么”
    ↓
技能说明“这类任务应该怎样完成”
    ↓
检索与上下文系统提供“当前需要知道什么”
    ↓
工具负责“执行具体动作”
    ↓
运行支撑系统控制“这次执行怎样发生”
    ↓
闭环根据反馈持续检查和修正
    ↓
评测判断结果是否真正达标

用一句话概括：

规格定义目标，工单划分任务，技能提供方法，检索提供知识，上下文组织信息，工具执行动作，运行支撑系统控制过程，闭环推动收敛，评测提供证据。

这些部分不能相互替代。

例如：

• 检索增强生成不能替代技能；
• 技能不能替代工具；
• 工单不能替代规格；
• 长期记忆不能替代权威任务状态；
• 模型自我评价不能替代测试；
• 多智能体不能自动解决错误的任务拆分。

---

二、提示词工程：告诉模型“这一次怎么回答”

提示词（Prompt）是发送给模型的自然语言或结构化指令。

提示词工程主要关注：

• 角色设定；
• 任务描述；
• 示例；
• 输出格式；
• 禁止事项；
• 回答风格；
• 推理约束。

例如：

你是一名资深 Python 工程师。

请检查下面代码中的逻辑错误，并按照以下格式输出：

1. 错误位置；
2. 错误原因；
3. 修复建议；
4. 修复后的代码。

它解决的是：

一次模型调用应该怎样组织指令

提示词工程很重要，但它的能力边界也很明显。

仅靠提示词，通常无法可靠解决：

• 应该读取哪些文件；
• 如何从上千个文件中找到相关代码；
• 工具调用失败后怎么办；
• 任务执行到一半如何恢复；
• 如何验证修改没有破坏其他功能；
• 哪些操作需要人工审批；
• 如何让多个智能体并行工作。

因此，提示词只是智能体系统的一部分，而不是整个智能体系统。

---

三、检索增强生成：让模型在回答前查询外部知识

检索增强生成是一种“先检索、再生成”的方法。

基本流程是：

用户问题
   ↓
查询知识库或文档库
   ↓
找到相关内容
   ↓
把相关内容交给模型
   ↓
模型结合检索结果生成回答

2020 年发表的经典工作将检索器、外部非参数化知识库和生成模型结合起来，用于知识密集型自然语言处理任务。这篇论文也使“检索增强生成”这一名称得到广泛传播。

检索增强生成解决什么问题

大语言模型的参数中保存了大量知识，但这些知识可能：

• 已经过时；
• 不包含私有资料；
• 无法精确定位来源；
• 不包含某个项目的内部文档；
• 难以快速更新。

检索增强生成通过外部知识库补充模型，使系统能够查询：

• 企业文档；
• 论文库；
• 产品手册；
• 代码仓库；
• 数据库记录；
• 用户上传文件；
• 最新业务资料。

检索增强生成不等于上下文工程

检索增强生成主要解决：

从外部知识库中找出哪些资料。

上下文工程则进一步解决：

找到资料以后，哪些内容应该以什么形式进入当前上下文？

例如，系统检索到 100 个文档片段，不代表应该把 100 个片段全部交给模型。

还需要经过：

• 去重；
• 排序；
• 可信度筛选；
• 权限检查；
• 摘要；
• 压缩；
• 冲突检测；
• 来源标记。

因此，可以把两者理解为：

检索增强生成：负责寻找候选知识

上下文工程：负责组织最终交给模型的信息

---

四、上下文工程：决定模型此刻应该看到什么

上下文（Context）是模型当前一次推理能够直接看到的信息。

它可能包括：

• 系统指令；
• 用户问题；
• 当前工单；
• 相关技能；
• 检索到的资料；
• 相关源代码；
• 工具说明；
• 历史执行摘要；
• 测试日志；
• 长期记忆；
• 当前权限；
• 已知风险。

上下文工程并不是最近才突然出现的技术。

信息检索、对话状态管理、提示词构建、文档筛选、历史摘要和外部记忆都已经发展多年。“上下文工程”是对这些方法在大语言模型系统中的进一步归纳。

上下文工程主要处理四个问题。

1. 放入什么

只向模型提供当前任务真正需要的信息。

2. 排除什么

排除：

• 无关文件；
• 重复资料；
• 过期方案；
• 已废弃接口；
• 不可信指令；
• 与当前工单无关的历史对话。

3. 以什么形式放入

同一份信息可以表现为：

• 完整原文；
• 摘要；
• 表格；
• 结构化数据；
• 文件引用；
• 图关系；
• 检索片段。

4. 什么时候更新

工具运行、测试失败、用户修改需求或工单状态变化后，上下文也要随之更新。

所以，上下文不是一段固定提示词，而是智能体运行过程中的动态工作区。

---

五、规格工程：明确整个项目究竟要实现什么

规格说明（Specification）负责把模糊需求转换成稳定、明确、可验证的目标。

用户最初可能只说：

帮我做一个科研助手。

但这句话没有说明：

• 面向哪个研究领域；
• 要处理什么数据；
• 是搜索论文还是执行实验；
• 是否调用论文原始代码；
• 是否允许自动修改项目；
• 哪些操作需要人工确认；
• 如何证明结果可信。

经过规格化以后，需求可能变成：

系统需要检索指定主题的正式论文和预印本，
定位论文对应的原始代码仓库，
提取研究方法和实验配置，
在真实数据上执行复现实验，
并为每项结论记录来源和证据边界。

一份较完整的规格通常包括：

• 项目背景；
• 目标；
• 非目标；
• 使用者；
• 功能要求；
• 非功能要求；
• 数据约束；
• 权限边界；
• 验收条件；
• 风险；
• 未决问题。

规格回答的是：

整个功能或项目最后应该是什么样子？

但规格一般仍然过大，不能直接交给一个智能体一次完成，因此还需要工单工程。

---

六、工单工程：把大目标拆成可独立交付的任务

工单（Ticket）是一个边界明确、可以执行、可以验收的工作单元。

“工单工程”目前还不是一个已经形成统一标准的正式学科名称。这里用它概括围绕任务拆解、依赖管理、状态管理和验收条件形成的工程实践。

Matt Pocock 的 to-tickets 技能是一个有代表性的案例。它要求将规格、计划或当前对话拆成一组“曳光弹式纵向切片”，每张工单都应形成一条窄而完整的功能路径，并明确声明阻塞关系。

1. 横向拆分与纵向拆分

常见的横向拆分方式是：

工单一：设计数据库
工单二：编写后端
工单三：编写前端
工单四：补充测试

这种拆法的问题是，每张工单只完成系统的一层。

数据库完成后，用户还不能使用；后端完成后，仍然看不到完整结果。问题通常要到最后集成时才集中暴露。

纵向拆分则是：

工单一：实现用户创建项目的最小闭环

包括：
- 最小数据结构；
- 创建接口；
- 必要业务规则；
- 用户调用入口；
- 结果反馈；
- 自动化测试。

这张工单虽然只实现一个很小的功能，但已经贯穿输入、处理、存储、输出和验证。

判断工单是否合理，不应只看工作量，而应看：

工单完成后，是否增加了一项能够独立演示或验证的能力？

2. 工单不是普通待办事项

下面这种内容只是模糊待办：

优化记忆模块。

它没有说明优化什么，也无法判断何时完成。

一张合格工单通常应包含：

标题
目标
背景
输入
输出
范围
非范围
验收条件
前置依赖
风险
人工审核要求

例如：

# 实现论文方法章节提取

## 目标

从已经解析的论文正文中识别方法章节，
输出结构化方法记录，并保留原文位置。

## 输入

- 论文正文；
- 章节层级；
- 页码；
- 论文来源记录。

## 输出

- 方法记录；
- 提取报告；
- 无法确定的章节列表。

## 验收条件

- 能识别常见的方法章节标题；
- 输出满足规定的数据结构；
- 每条记录能够定位回原文；
- 无法确定时标记为不确定；
- 自动化测试通过。

## 前置依赖

- 论文正文解析；
- 章节分割。

工单完成的标准不是：

智能体说“已经完成”。

而是：

规定产物已经生成，
验收条件已经通过，
依赖状态已经更新，
执行证据已经保存。

3. 工单会形成任务依赖图

复杂项目中的工单不是普通列表，而是一个任务依赖图：

工单一 ───┐
          ├──→ 工单四 ───→ 工单六
工单二 ───┘
工单三 ───────→ 工单五 ──┘

如果工单四依赖工单一和工单二，那么前两张工单完成之前，工单四不能开始。

所有前置依赖均已满足的任务，可以构成可执行前沿（Execution Frontier）：

可执行前沿
=
当前能够立即领取和执行的全部工单

有了任务依赖图，多个智能体才能在不破坏依赖关系的情况下并行工作。

---

七、技能工程：把可复用的工作方法封装起来

技能（Skill）说明的是：

遇到某一类任务时，智能体应该按照什么方法完成。

例如：

工单：
检查本次数据库迁移是否安全。

技能：
数据库迁移安全审查。

同一个数据库迁移安全审查技能，可以被多个项目和多个工单重复使用。

智能体技能规范（Agent Skills Specification）将一个技能定义为至少包含 SKILL.md 文件的目录，还可以附带脚本、参考资料和模板等资源。

一个技能通常需要包含：

• 适用场景；
• 不适用场景；
• 必需输入；
• 操作步骤；
• 可调用工具；
• 输出格式；
• 风险限制；
• 验证方式；
• 异常处理；
• 参考资料。

技能不是工具。

技能：怎样检查数据库迁移。

工具：
- 读取迁移文件；
- 启动测试数据库；
- 执行迁移命令；
- 查询数据库结构；
- 保存测试结果。

工具负责动作，技能负责组织动作的方法。

---

八、一张工单会对技能提出哪些要求

工单拆得再好，如果没有合格的技能，智能体仍然只能临场猜测。

一张可执行工单至少会对技能提出以下要求。

1. 技能必须能够被正确发现

技能需要清楚说明：

• 什么情况下使用；
• 什么情况下不使用。

模糊描述：

处理数据库问题。

更准确的描述：

用于检查数据库迁移中的结构兼容性、
数据丢失风险、回滚能力和重复执行安全性。
不用于普通查询优化。

在智能体技能规范中，技能描述是系统判断是否加载技能的重要依据；描述过窄会导致技能无法触发，描述过宽则会导致错误触发。

2. 技能必须有明确边界

过小的技能：

打开文件。

这更接近工具动作。

过大的技能：

完成整个科研项目，包括文献检索、实验执行、
数据分析、统计推断和论文写作。

这已经是完整工作流，不再是边界稳定的可复用技能。

合适的技能通常对应一项稳定能力，例如：

• 提取论文方法；
• 审查代码变更；
• 验证实验可重复性；
• 分析持续集成失败；
• 检查数据库迁移；
• 生成工单依赖图。

3. 技能必须声明输入

例如，数据库迁移审查可能需要：

必需输入：
- 迁移脚本；
- 当前数据库结构；
- 目标数据库结构；
- 回滚脚本；
- 测试数据库。

可选输入：
- 历史故障记录；
- 数据规模；
- 停机限制。

缺少必需输入时，技能不能自行编造。

4. 技能必须声明输出

“完成分析”不是明确输出。

技能应说明会生成：

- 迁移风险报告；
- 数据结构差异；
- 正向迁移记录；
- 回滚测试记录；
- 未解决问题列表。

只有输出明确，工单才能自动验收。

5. 技能必须提供验证方式

一句：

迁移是安全的。

不能算有效证据。

更可靠的验证包括：

• 测试数据库迁移成功；
• 回滚成功；
• 迁移前后关键数据一致；
• 数据库约束仍然存在；
• 重复执行不会产生额外副作用；
• 错误路径经过测试。

可以将其概括为：

智能体的结论只是主张，测试、日志、产物和来源才构成证据。

6. 技能必须声明依赖

技能可能依赖：

• 其他技能；
• 文件读取工具；
• 命令执行工具；
• 浏览器；
• 数据库；
• 特定软件；
• 环境变量；
• 外部权限。

只有依赖明确，调度系统才能判断工单是否真正可执行。

7. 技能必须声明副作用

技能应该明确是否会：

• 修改代码；
• 修改数据库；
• 创建工单；
• 提交代码；
• 发布版本；
• 发送消息；
• 删除资源；
• 调用付费服务。

可以将技能划分为：

只读技能
可回滚写入技能
高风险写入技能
不可逆操作技能

高风险副作用需要权限控制和人工审批。

8. 技能应支持幂等性

幂等性（Idempotency）是指同一任务被再次执行时，不会产生失控的重复副作用。

例如，不应因为任务重试而：

• 重复创建同一工单；
• 重复提交同一代码；
• 重复发送同一通知；
• 重复写入相同数据。

长期任务还应支持检查点（Checkpoint）和恢复（Recovery），避免每次失败都从头开始。

9. 技能必须控制上下文规模

技能不应把所有材料一次性交给模型。

智能体技能规范建议主技能文件只保留每次运行普遍需要的核心说明，详细资料放入参考文件，并在需要时加载。

原则可以概括为：

高频规则放在主文件；
低频资料按需加载；
确定性操作交给脚本；
大体量资料不要长期占用上下文。

10. 技能必须留下审计证据

执行完成后，系统需要知道：

• 使用了哪个技能版本；
• 输入来自哪里；
• 调用了哪些工具；
• 修改了哪些文件；
• 执行了哪些命令；
• 是否发生重试；
• 哪些结论经过人工确认；
• 什么证据支持完成状态。

这使技能从“给模型看的操作建议”，变成“可以检查的执行协议”。

---

九、模型上下文协议：统一连接外部工具和数据

模型上下文协议（Model Context Protocol，MCP）用于标准化模型应用与外部工具、数据源和服务之间的连接方式。

它试图解决的问题是：

不同智能体怎样用统一方式发现和调用外部能力？

例如，一个智能体可能需要连接：

• 文件系统；
• GitHub；
• 数据库；
• 搜索服务；
• 企业知识库；
• 项目管理平台。

需要注意：

模型上下文协议不是技能；
模型上下文协议不是检索增强生成；
模型上下文协议也不是运行支撑系统。

它更接近一种工具和资源连接协议。

可以这样理解：

技能：
规定怎样完成任务。

模型上下文协议：
规定怎样连接外部能力。

工具：
真正执行外部动作。

运行支撑系统：
决定何时调用、如何授权、怎样处理结果。

---

十、智能体运行支撑工程：模型之外的执行系统

智能体运行支撑工程是指围绕模型建立执行环境、工具循环、状态管理、权限控制和反馈机制。

这里的 Harness 原意接近“驾驭、约束和支撑系统”。

OpenAI 将其描述为：通过设计环境、明确意图和建立反馈循环，使代码智能体能够可靠工作；在 Codex 中，运行支撑系统还负责协调用户、模型和工具之间的交互。

模型本身通常只负责：

接收上下文
→ 生成下一步输出

运行支撑系统则负责：

解释模型输出
→ 判断是否调用工具
→ 执行工具
→ 收集工具结果
→ 更新上下文
→ 再次调用模型
→ 判断是否结束

完整的运行支撑系统通常包括：

• 模型调用；
• 提示词和上下文组装；
• 技能加载；
• 工具注册；
• 工具执行；
• 权限控制；
• 沙箱隔离；
• 超时；
• 状态持久化；
• 日志；
• 重试；
• 检查点；
• 人工审批；
• 结果验证。

因此：

智能体系统
≠ 单独的大语言模型

更准确地说：

智能体系统
=
模型
+ 运行支撑系统
+ 技能
+ 工具
+ 状态
+ 执行环境

同一个模型放入不同的运行支撑系统中，可能呈现完全不同的可靠性。

---

十一、智能体闭环工程：让系统根据反馈持续纠错

智能体循环（Agent Loop）是智能体运行的基本结构：

模型推理
→ 调用工具
→ 获得环境反馈
→ 模型继续推理

OpenAI 将智能体循环描述为协调用户、模型和工具交互的核心逻辑。

本文所说的智能体闭环工程，是对这种循环进行工程化扩展：

理解任务
→ 制定计划
→ 执行动作
→ 检查结果
→ 发现差距
→ 修改计划
→ 再次执行
→ 满足停止条件

“闭环工程”目前并不是一个已经形成统一标准的正式术语。这里用它概括围绕反馈、验证、重试、重新规划和停止条件形成的工程实践。

一个可靠闭环至少需要七个部分

1. 触发条件

例如：

• 用户提交工单；
• 持续集成失败；
• 出现新数据；
• 定时任务启动；
• 外部系统产生事件。

2. 当前状态

系统必须知道：

• 已经完成什么；
• 当前正在做什么；
• 哪些任务失败；
• 哪些任务被阻塞；
• 哪些操作等待审批。

3. 执行者

执行者可以是：

• 主智能体；
• 子智能体；
• 确定性脚本；
• 人工。

4. 环境反馈

例如：

• 测试结果；
• 编译错误；
• 数据库返回；
• 代码审查意见；
• 性能指标；
• 用户反馈。

5. 验证器

验证器负责独立判断结果是否达到标准。

6. 停止条件

例如：

测试全部通过；
验收条件全部满足；
不存在未处理的高风险问题。

7. 预算和失败限制

防止智能体：

• 无限重试；
• 重复同一种错误；
• 不断扩大任务范围；
• 消耗失控；
• 长时间没有实质进展。

执行者—复核者模式

执行者—复核者模式（Maker–Checker Pattern）是闭环中的常见结构：

执行者生成结果
   ↓
复核者独立检查
   ↓
发现问题
   ↓
执行者修改
   ↓
重新验证

核心原则是：

生成结果的一方，不应只凭自己的判断宣布任务完成。

复核机制可以包括：

• 单元测试；
• 集成测试；
• 静态分析；
• 数据结构验证；
• 独立智能体；
• 人工审核。

---

十二、运行支撑工程和闭环工程有什么区别

两者关系紧密，但关注层级不同。

概念	解决的问题
运行支撑工程	一次智能体执行怎样安全、可靠地发生
闭环工程	多次执行怎样根据反馈修正并收敛
编排工程	多个工单和智能体怎样协调
评测工程	怎样证明整个系统可靠有效

可以用汽车作类比：

模型：发动机

技能：驾驶方法和操作规程

工具：方向盘、刹车和仪表

运行支撑系统：车辆控制与安全系统

闭环：根据道路和导航持续纠偏

编排系统：车队调度中心

---

十三、多智能体编排：协调多个工单和执行者

多智能体编排负责：

• 根据依赖选择任务；
• 为任务分配智能体；
• 创建隔离工作区；
• 控制并发；
• 管理任务租约；
• 监测智能体卡死；
• 重启失败任务；
• 合并结果；
• 处理代码冲突；
• 控制成本。

这里需要区分：

闭环：
一个任务怎样不断推进。

编排：
多个任务和智能体怎样协同。

如果工单拆分错误，即使增加更多智能体，也只会更快地制造冲突。

---

十四、记忆与状态工程：什么信息应该被长期保留

智能体长期运行时，需要区分三类信息。

1. 当前上下文

模型本轮直接看到的信息。

它容量有限，也可能在摘要或压缩后丢失细节。

2. 智能体记忆

智能体记忆（Agent Memory）保存未来任务可能复用的信息，例如：

• 用户偏好；
• 项目术语；
• 失败经验；
• 常用方法；
• 已确认的架构决策。

3. 权威状态

权威状态（Authoritative State）决定系统的真实情况，例如：

• 工单是否完成；
• 哪个版本已经发布；
• 哪个实验使用了哪份数据；
• 人工审批是否通过；
• 当前由谁持有任务。

权威状态不能只依赖模型记忆。

例如，“工单已经完成”应由：

任务状态
+ 验收记录
+ 产物证据

共同确定，而不是因为智能体曾经在对话中说过“已经完成”。

---

十五、智能体评测：证明任务是不是真的完成

普通模型评测通常关注一问一答是否正确。

但智能体会：

• 多次调用模型；
• 调用工具；
• 修改外部环境；
• 根据中间结果调整计划；
• 产生真实副作用。

因此，智能体评测不能只检查最终回答。

还需要评估：

• 任务是否真正完成；
• 工具选择是否正确；
• 工具参数是否正确；
• 是否修改无关文件；
• 是否违反权限；
• 是否完成全部验收条件；
• 是否发生不必要的重试；
• 是否可以从失败恢复；
• 成本和耗时是否合理；
• 是否需要过多人工介入。

例如，一个智能体最终修复了错误，但同时：

删除了无关文件；
绕过了测试；
修改了生产数据库。

从最终回答看，它可能成功了；从系统工程角度看，它显然失败了。

---

十六、可观测性与治理：知道系统做了什么，也知道谁负责

可观测性要求系统能够回答：

任务来自哪里？
使用了哪个规格？
拆成哪些工单？
选择了哪些技能？
检索了哪些资料？
调用了哪些工具？
修改了哪些资源？
哪一步失败？
为什么重试？
谁批准了高风险操作？
依据什么判断任务完成？

较完整的记录包括：

• 任务编号；
• 智能体编号；
• 技能版本；
• 输入摘要和哈希；
• 检索来源；
• 工具调用；
• 文件变更；
• 测试结果；
• 错误分类；
• 状态变化；
• 人工审批；
• 最终证据。

人机协同则需要确定：

• 哪些操作可以自动执行；
• 哪些操作可以执行后抽查；
• 哪些操作必须事先批准；
• 哪些操作永远禁止自动执行。

例如，以下操作通常需要人工审批：

• 合并关键代码；
• 发布生产版本；
• 修改生产数据库；
• 删除数据；
• 改变科研主要结论；
• 向外部用户发送正式信息。

自动化程度越高，责任边界越需要明确。

---

十七、这些概念怎样组成完整的智能体系统

可以把整个体系整理为十一层：

第一层：提示词工程
组织一次模型调用中的指令。

第二层：检索增强生成
从外部知识库获得候选知识。

第三层：上下文工程
选择和组织当前步骤所需的信息。

第四层：规格工程
明确项目目标、范围和验收要求。

第五层：工单工程
将目标拆成可执行任务和依赖图。

第六层：技能工程
提供可复用的任务方法。

第七层：工具接口工程
提供真实动作能力。

第八层：运行支撑工程
管理模型、工具、权限、状态和故障。

第九层：闭环与编排工程
根据反馈持续纠错，并协调多个任务。

第十层：记忆、评测与可观测性
保留状态、证明结果并定位问题。

第十一层：人工治理
决定高风险事项和最终责任。

进一步压缩成一句话：

提示词表达指令，检索寻找知识，上下文组织信息，规格确定目标，工单划分边界，技能提供方法，工具执行动作，运行支撑系统控制过程，闭环推动收敛，评测提供证据，人类承担最终责任。

---

十八、用一个科研助手案例串起来

假设目标是：

为科研助手增加论文方法复现能力。

第一步：形成规格

明确：

• 支持哪些论文；
• 是否查找原始代码；
• 是否读取补充材料；
• 是否自动生成实验配置；
• 是否必须运行真实实验；
• 如何记录与原论文的偏差；
• 哪些结论需要人工审核。

第二步：使用检索增强生成

检索：

• 论文正文；
• 补充材料；
• 作者项目页；
• 原始代码仓库；
• 数据集说明；
• 后续修正或勘误。

第三步：拆成工单

工单一：解析论文方法章节
工单二：定位原始代码仓库
工单三：提取实验配置
工单四：构建最小复现实验
工单五：执行真实实验
工单六：比较原始结果和复现结果
工单七：生成证据边界报告

第四步：为工单匹配技能

例如：

论文结构提取技能
代码仓库审查技能
配置提取技能
实验执行技能
统计比较技能
证据边界审查技能

第五步：运行支撑系统准备环境

• 创建隔离工作区；
• 加载论文和代码；
• 设置权限；
• 准备运行环境；
• 注册工具；
• 建立权威任务状态。

第六步：进入闭环

执行实验
→ 检查错误日志
→ 修复环境问题
→ 再次执行
→ 比较结果
→ 发现差异
→ 分析原因
→ 修改配置
→ 重新运行

第七步：验证

最终不能只输出：

论文已经成功复现。

而应提供：

• 论文版本；
• 代码提交版本；
• 数据版本；
• 环境配置；
• 实际执行命令；
• 随机种子；
• 原论文结果；
• 当前实验结果；
• 结果差异；
• 未验证部分；
• 支持与不支持的结论。

这就是从“让模型回答问题”，升级为“建立可审计智能体系统”的区别。

---

十九、不要把所有名词都当成成熟标准

这些概念的成熟程度并不相同。

已有长期技术基础

• 信息检索；
• 提示词构建；
• 上下文选择；
• 状态管理；
• 工具调用；
• 工作流；
• 任务队列；
• 反馈循环；
• 自动化测试；
• 权限控制。

已经形成公开格式或研究定义

• 检索增强生成；
• 智能体技能规范；
• SKILL.md；
• 模型上下文协议；
• 智能体循环。

正在形成的工程概括

• 工单工程；
• 技能工程；
• 智能体运行支撑工程；
• 智能体闭环工程；
• 智能体软件工厂。

后面这些名称对应的工程问题是真实存在的，但目前并不都具有唯一、稳定、被所有团队接受的定义。

讨论它们时，最重要的不是争论名称，而是回答：

输入是什么？
输出是什么？
使用什么知识？
选择什么技能？
调用什么工具？
怎样验证？
失败后怎么办？
什么时候停止？
什么时候必须交给人？

---

总结

完整的智能体系统不只是一个大语言模型，也不只是一个写得很长的提示词。

它至少包含：

提示词
+ 检索增强生成
+ 上下文
+ 规格
+ 工单
+ 技能
+ 工具
+ 运行支撑系统
+ 智能体闭环
+ 编排
+ 记忆与状态
+ 评测
+ 可观测性
+ 人工治理

to-tickets 的意义也不只是把需求拆成几张问题单。

它进一步揭示了工单对整个智能体系统的要求：

工单必须有清晰边界；
技能必须可以正确发现；
输入输出必须明确；
检索资料必须有来源；
任务依赖必须能够计算；
执行环境必须隔离；
副作用必须受到控制；
结果必须能够验证；
失败必须可以恢复；
完成状态必须有证据。

真正成熟的智能体，不是能够流畅地说“任务已经完成”。

而是整个系统能够证明：

它在明确的规格、权限和证据要求下，检索了可信知识，选择了合适技能，调用了受控工具，完成了可验证工单，并且在失败时能够恢复，在不确定时知道何时交给人类。