AI Agent 的可靠性边界：Skills、RAG 与权限能解决什么
从上下文、证据、执行和治理四个层面拆解 Agent 的可靠性瓶颈，对比 Claude Code、Codex、Kimi 与 WorkBuddy 的实际作用，并给出可验收的落地路径。
阅读导航 · 本篇目录
AI Agent 已经能承担大量实际工作，但能否放心交付，取决于它能否在明确边界内持续做对，并在做错时被发现、被恢复。
这也是理解 Claude Code、Codex、Kimi、WorkBuddy 的起点。它们通过模型、工具、上下文管理和执行环境扩大了可自动化的范围，但没有消除事实错误、长任务偏航和授权范围内的误操作。
面对这些问题，可以先建立三个判断：
- 能力增加需要配套管理。 更多 Skills、更长上下文和更多检索结果，只有在相关、清晰、可验证时才有价值。
- 产品提供执行基础，业务仍需定义正确。 工具能帮助 Agent 读资料、改文件、运行程序，却不能自动补齐企业隐含的规则和验收标准。
- 自动化应随证据逐步扩大。 优先交付边界清楚、结果可检查、失败可恢复的任务，再根据实际运行记录增加权限和自治范围。
本文围绕这三个判断展开：先解释瓶颈，再比较产品，最后给出落地方法。
[!NOTE] 产品能力依据 2026 年 9 月 4 日查阅的官方文档整理。文中的产品定位和落地建议属于分析判断，不是四款产品的横向实测排名；历史研究和厂商评测也不能直接换算成当前产品的任务成功率。
一、Agent 的能力越多，越需要管理可靠性
一次任务通常要经过理解目标、获取信息、制定方案、调用工具和验收结果。任何一个环节出错，都可能让后续工作建立在错误前提上。
为了便于定位，可以把主要问题分为四层：上下文是否有效、证据是否充分、执行是否正确、行为是否受控。这个分类按失败位置组织；同一个事故可能涉及多层。
| 层次 | 核心问题 | 典型失败 | 主要缓解方式 |
|---|---|---|---|
| 上下文 | 当前决策看到了什么 | 技能选错、约束遗忘、日志淹没重点 | 按需加载、明确触发条件、结构化状态 |
| 证据 | 判断依据是否充分可信 | 检索遗漏、资料过期、口径冲突 | 来源追溯、版本管理、精确查询、信息不足时停止下结论 |
| 执行 | 操作是否达成目标 | 长任务偏航、重复写入、过早宣布完成 | 分阶段验收、状态回读、检查点和失败恢复 |
| 治理 | 行为是否处于可接受边界 | 越权访问、误发送、提示注入、无法追责 | 最小权限、执行隔离、操作审批和审计 |
1. Skills 的问题在于加载与选择方式，不能只看安装数量
Skills 通常由说明、脚本、模板和参考资料组成。安装一个 Skill，并不会直接改变模型参数。执行任务时，模型仍要识别用途、理解步骤、选择工具并检查结果。
因此，“技能多了以后变差”至少有三种不同原因。
第一，目录难以区分。 如果多个技能都写着“用于调研、分析、整理信息”，模型很难判断何时使用哪一个。正文尚未加载，路由已经可能出错。
第二，正文引入过量要求。 某个技能要求查阅多个参考文件，另一个要求固定输出模板，第三个要求完整执行一套流程。单独看都合理，合在一个简单任务里却可能增加冲突和无效步骤。
第三，执行过程不断累积信息。 搜索结果、报错、重试日志和中间文件进入上下文后，会与真正重要的约束竞争。任务开始时选对了技能，也不意味着执行到后半程仍能守住重点。
Claude Code 和 Codex 都采用按需加载技能正文的方式。Codex 当前文档还说明，初始技能列表受到预算限制；技能过多时会缩短描述，部分技能可能从初始列表中省略。这样可以控制上下文占用，也意味着技能是否被正确发现，需要单独验证。Claude Code Skills、Codex Skills
| 观察到的现象 | 应优先检查什么 |
|---|---|
| 明明装了技能，却一直没有使用 | 技能是否被发现、描述是否清楚、任务是否匹配 |
| 经常调用不相关技能 | 触发条件是否过宽，多个技能是否重叠 |
| 加载技能后任务明显变长 | 正文是否要求多余步骤，引用资料是否过多 |
| 工作到后半程忘记要求 | 上下文是否被中间结果挤占，摘要是否保留关键约束 |
| 使用技能后更稳定 | 是否把易错操作封装为脚本，是否提供了明确的验收方法 |
Anthropic 的工具搜索实验给出了一项相关证据：在其内部 MCP 评测中，按需查找工具后，Opus 4 的准确率从 49% 提升至 74%，Opus 4.5 从 79.5% 提升至 88.1%。这是特定模型和评测条件下的结果，说明工具组织方式会影响表现，不能据此推导一个通用的“安全技能数量”。工具搜索实验
更合理的优化目标是：让每一步得到足够且相关的信息，让稳定操作尽量由可靠脚本完成。
2. RAG 补充证据，但无法包办推理、执行和验收
RAG，即检索增强生成，是先检索资料，再将资料交给模型辅助回答。它很适合补充内部知识、最新信息和可追溯依据。
但一次可靠交付需要满足一整条条件链：
找到资料 → 资料足够且可信 → 正确理解 → 正确决策 → 正确执行 → 验证结果
RAG 主要改善信息获取，不能直接保证后续环节。
以“解释本月销售额下降”为例，检索系统可能找到上月报告、渠道总结和销售会议纪要。但这些内容可能遗漏退款数据，也可能混用了下单金额、回款金额和确认收入。即使资料齐全，模型仍可能把促销减少与销售下降的相关性，当成已经成立的因果关系。
如果问题变成“精确计算每个渠道的净收入”，更合适的做法通常是查询完整业务数据，再用 SQL 或代码计算。只检索几段相关文字，无法证明所有记录都已覆盖。
《Sufficient Context》研究区分了两类错误：检索上下文不足以回答问题，以及模型没有正确利用足够的上下文。研究还观察到，部分受测模型在信息不足时仍会作答。它说明，RAG 系统除了检索，还需要判断证据是否足够。研究原文
| 问题 | 仅增加检索结果为什么不够 | 需要补上的机制 |
|---|---|---|
| 核心资料不存在 | 检索无法提供从未记录的信息 | 补充数据，明确缺口 |
| 多个版本相互矛盾 | 更多结果可能增加冲突 | 生效日期、来源优先级、版本管理 |
| 需要精确统计全部记录 | 相关片段不等于完整数据集 | 数据库查询、程序计算、总量对账 |
| 需要判断因果关系 | 找到共同变化不等于证明原因 | 对照证据、实验或适用的分析方法 |
| 回答后需要修改业务系统 | 检索能力不提供执行授权 | 独立的工具、权限和验收流程 |
权限还必须作用于检索本身。无权访问的资料不应先进入模型上下文，再依靠一句“请勿泄露”保护。过滤需要覆盖检索、缓存、引用和最终输出所经过的数据路径。
3. 长任务的困难在于连续正确与及时纠错
Agent 会做每个单独步骤，不代表它能稳定完成整条工作流。
做一个简化计算：假设任务包含 30 个必须成功的步骤，每一步独立成功率为 98%，且没有重试与纠错，那么全部成功的概率为：
这只是说明错误累积的假设模型。真实步骤并不独立，系统也可能恢复，因此不能用这个数估计某个产品的成功率。它揭示的问题是：可靠性需要在任务过程中被维护，不能只在最后检查一次。
Anthropic 在长任务工程实践中记录过两类失败：试图一次完成过多内容，导致下一轮难以接手；看到已有进展，就过早宣布整个任务完成。它通过增量工作、进度记录和 Git 历史等方式改善交接。长任务工程实践
执行环节还有一些更普通、也更容易造成损失的问题。接口超时后再次提交，可能生成重复记录；页面布局改变后，原来正确的点击位置可能指向另一个按钮；测试全部通过，也可能只是因为测试遗漏了真实需求。
因此，工具返回“成功”，只证明接口接受或完成了某种操作。最终仍需检查业务状态，例如记录是否写入正确账户、金额是否一致、邮件是否发给正确对象。
4. 权限控制限制行为范围，正确性仍需另行验证
“给 Agent 多大权限”包含多个不同问题。
| 层次 | 必须明确的内容 | 示例 |
|---|---|---|
| 身份认证 | 它代表谁行动 | 个人账号还是专用服务账号 |
| 资源授权 | 它能访问什么 | 哪些目录、文档、客户记录 |
| 行为授权 | 它可以做什么 | 读取、起草、修改、发送、删除 |
| 执行隔离 | 它能影响哪些环境 | 工作目录、网络目标、测试环境 |
| 审计与恢复 | 出错后如何定位和处理 | 操作日志、备份、撤销和责任人 |
读取客户资料、生成邮件草稿、向全部客户发送邮件，是三种不同授权。拥有数据库写权限，也不意味着写入的金额符合业务规则。
Codex 的官方文档将沙箱与审批策略分开：前者约束技术上能做什么，后者决定何时需要批准。Claude Code 同样提供权限控制与提示注入防御。它们能降低风险，但不能保证授权范围内的所有操作都正确。Codex 权限与安全、Claude Code 安全
提示注入进一步扩大了问题：Agent 读取的网页、文档或工具结果，可能包含试图改变任务目标的指令。系统需要区分可信指令与外部数据，并限制数据流向和工具能力。让同一个模型自行识别全部恶意内容，不足以构成完整防线。
二、四类产品扩大了执行能力，但业务正确性仍需共同建设
理解产品价值，可以把一个 Agent 系统看成模型与执行环境的组合。模型负责理解、推理和选择；执行环境负责提供工具、维护状态、处理权限，并呈现结果。后面这部分通常被称为 Agent Harness。
Claude Code、Codex、Kimi 和 WorkBuddy 的实际贡献，是让更多工作进入“能够操作、能够观察、能够继续推进”的流程。 它们的使用入口与侧重点不同，能力也在相互重叠。
1. 开发型 Agent 让代码任务具备执行与反馈循环
Claude Code 可以阅读代码库、跨文件修改、运行验证、处理 Git 操作，并通过 MCP 连接外部工具。它的价值包括把一段问题描述推进为可检查的代码变更，而不只停留在解释层面。Claude Code 官方说明
Codex 同样提供检查代码、编辑文件、运行命令、审查变更和编排重复工作流的能力，还可以通过 Skills 和插件接入工具与数据。对开发工作而言，这让“修改—运行—观察—修正”能够连续发生。Codex 官方说明
但代码可以运行，仍不等于产品需求正确。一个需求不完整、依赖复杂、缺少验收条件的项目，不会因为接入开发型 Agent 就自动变得清晰。架构取舍、隐含业务规则和漏测场景，仍需要团队提供依据。
2. Kimi 的不同入口分别服务研究、产物制作与开发
讨论 Kimi 时，需要区分通用 Agent、Agent Swarm 和 Kimi Code。
Agent Swarm 将任务拆给多个执行主体，适合大范围检索、批量阅读和其他可以并行的工作。它可以让每个子任务保留自己的上下文，再由主 Agent 汇总。Kimi Agent Swarm
这种组织方式能缓解单个上下文的负担，但会带来分工、交接和汇总成本。多个 Agent 引用同一条错误消息，不构成独立证据；多个局部结果正确，也可能因为口径不一致而无法直接合并。这是使用多 Agent 时需要另外验证的工程问题。
Kimi Code 则进入终端或编辑器，支持编写代码、修复问题、生成文档和使用 Skills。它应与开发型 Agent 放在相同任务条件下比较，而不能把整个 Kimi 产品家族当成单一工具。Kimi Code Skills
3. WorkBuddy 降低了办公任务自动化的操作门槛
WorkBuddy 的官方定位是办公工作台，覆盖报告、文档、表格、PPT、数据分析和授权目录内的文件处理。它让使用者通过自然语言发起任务，并取得可查看的产物。WorkBuddy 官方说明
对办公场景而言，接入文件和交付产物很有价值。但报表中的数字口径、材料的适用版本、对外发布规则和异常处理方式，仍需由组织明确。文件格式完整，是验收的一部分；业务内容正确，是另一部分。
4. 选择产品，应围绕任务条件做比较
下面的表格是基于官方能力的使用判断，不是准确率或性能排名。
| 产品或入口 | 值得优先验证的任务 | 已提供的帮助 | 仍需补齐的条件 |
|---|---|---|---|
| Claude Code | 代码修改、调试、项目工作流 | 代码访问、工具执行、验证与流程复用 | 明确需求、有效测试、变更审查 |
| Codex | 代码修改、审查、脚本与重复工作流 | 本地执行、结果检查、工具扩展与权限控制 | 验收标准、运行环境、数据和发布边界 |
| Kimi Agent / Swarm | 资料研究、批量阅读、产物制作 | 搜索、任务分解和并行处理 | 来源质量、任务覆盖、统一汇总口径 |
| Kimi Code | 终端或编辑器内的开发任务 | 代码操作与技能复用 | 项目上下文、验证和权限设置 |
| WorkBuddy | 文档、表格、报告、批量文件处理 | 自然语言任务入口与办公产物交付 | 数据定义、异常规则、验收和发布授权 |
实际效果通常取决于四个条件：数据能否访问、接口是否稳定、结果能否验证、失败能否恢复。只有在相同任务、输入、权限和预算下，产品之间的成功率比较才有解释价值。
三、可靠落地应从验收出发，再逐步扩大自治范围
如果一开始就把目标设成“全自动完成整个岗位”，系统很难知道哪里算成功，也难以判断下一步应该改模型、工具还是流程。
更有效的路径是：把工作拆成可验收的任务，建立基线，定位失败，再逐步扩大自动化范围。
1. 先写清交付条件，再让 Agent 制订计划
“做一份经营报告”不是充分的任务定义。至少还应明确统计时间、数据源、指标口径、输出要求和遇到异常时的处理方式。
以周报为例，可以定义下面的工作链路：
| 阶段 | Agent 可以承担的工作 | 验收证据 |
|---|---|---|
| 收集 | 读取指定来源和时间范围的数据 | 来源清单、更新时间、记录数量 |
| 清洗 | 处理重复项、缺失值和格式 | 异常清单、处理规则、前后数量 |
| 计算 | 按固定定义计算指标 | 可复算代码、对账结果 |
| 分析 | 解释变化，提出待验证原因 | 事实与假设分开，结论对应证据 |
| 制作 | 生成文档、图表或演示材料 | 文件可打开，内容与统计一致 |
| 发布 | 按授权交付或发送 | 发布对象、版本和操作记录 |
每个阶段都留下证据，后续失败就可以从最近的有效状态恢复。人也不必重新检查所有原始材料，能够把注意力放在异常与关键判断上。
2. 用对照实验判断 Skills 是否真的造成退化
“最近感觉变笨了”可能来自技能变化，也可能来自模型版本、输入长度、工具故障或任务难度变化。诊断时应尽量固定其他条件。
可以在同一批代表性任务上比较三种配置：
| 配置 | 设置 | 主要观察什么 |
|---|---|---|
| A：相关技能集 | 只提供任务需要的技能 | 精简配置的表现基线 |
| B：完整技能集 | 提供全部技能，允许自动选择 | 目录扩大会不会造成误选或漏选 |
| C：完整技能集，指定技能 | 保留完整目录，显式指定相关技能 | 减少自动选择后能否恢复表现 |
各组应固定模型版本、任务输入、工具权限、运行环境和资源预算，并进行多次重复运行。初期可以先选少量真实任务定位问题；要估计总体成功率，需要足够且有代表性的样本，并报告不确定性。
如果 B 比 A 差、C 又有所恢复，路由可能是重要因素，但不能仅凭这个对照就证明全部原因。如果 A 与 C 都表现不佳，应继续检查技能正文、证据充分性和工具执行。若要专门测量上下文负担，还需要另设正文加载量的对照。
评估时至少记录：
- **验收通过率：**满足事先约定标准的任务占比。
- **遗漏率：**应完成的要求中，有多少未完成。
- **人工接管率：**有多少任务需要人介入才能继续。
- **副作用：**是否出现误写、重复操作或越权尝试。
- **交付成本：**耗时、调用费用、审核和返工时间。
“Agent 说已完成”只能算一个状态信号，不能直接计入验收成功。
3. 根据失败原因选择技术，避免无效叠加
Skills、RAG、记忆和多 Agent 都有适用条件。
| 已确认的瓶颈 | 优先尝试的改进 |
|---|---|
| 总是选错能力 | 缩小候选集，改善技能描述和适用边界 |
| 经常缺少关键资料 | 改善数据接入、检索覆盖和来源管理 |
| 同一操作反复出错 | 封装可靠脚本，增加参数和结果校验 |
| 长任务忘记进度 | 持久化结构化状态，设置阶段检查点 |
| 大量独立子任务执行太慢 | 在预算内并行，并明确汇总规则 |
| 输出看似完整但无法验收 | 补充独立检查、对账或人工评审 |
| 权限阻塞或误操作 | 细化授权范围，分开读取、草拟和发布 |
长期记忆也需要维护。保存一条经验，不等于模型已经学会正确判断。记忆应标记来源、适用范围和更新时间，并支持纠错与清理，否则过去的错误会成为未来的依据。
多 Agent 则需要计入协调成本。对于高度依赖前一步结果的工作，增加执行主体未必能缩短关键路径。衡量收益时，要把重复搜索、汇总、审核和返工一并计算。
4. 让自治范围随验证结果增长
对边界清楚、低风险、可恢复的任务，可以给 Agent 较大的自主空间，例如按固定规则转换文件、计算指标，或完成有明确验收条件的代码修改。
对需要解释证据、处理例外和跨系统协调的工作，更适合让 Agent 生成方案、执行授权部分，并把不确定处交给人判断。
对目标模糊、缺少可靠数据、结果难验证，同时又有高代价或不可逆后果的任务，目前不宜默认无人监督。这里需要的是更清楚的业务边界、更可靠的执行机制和更充分的运行证据。
采用 Agent 时，可以先从一条真实工作流开始：写下交付标准，授权必要工具，让它运行，检查结果，记录失败。下一次改进应能回答一个具体问题——减少了哪一种失败，节省了多少人工成本，是否引入了新的副作用。
能稳定通过验收的工作范围，才是 Agent 已经交付的能力。