跨领域模式归纳

前几章覆盖了不同领域：代码、研究、支持、数据分析和业务运营。它们的产物不同。补丁不是研究备忘录。退款不是 SQL 查询。支持升级处理不是代码审查。但相同的工程形状会反复出现。

本章只提升出现在多个领域中的模式。这里的模式不是提示词配方、人格设定、供应商模板或成熟度口号。它是一个可复用组合：问题、上下文、解决方案、权衡和失效边界。

核心论点

智能体系统中持久有效的模式是控制结构：限定范围的工作空间、带证据的上下文约定、权限边界、验证回路、可审查转换提议、升级处理默认路径、持久状态和运行后学习。只有当这些模式的前提也能迁移时，它们才可以跨领域迁移。

跨领域归纳有用，是因为它让团队识别反复出现的问题。但如果它抹掉了让模式在某个领域成立的具体证据，就会很危险。

模式 1：限定范围的工作空间

问题：智能体需要跨步骤保持连续性，但原始聊天历史不足以保存事实、所有权、产物、权限和进展。

上下文：出现在编码工作空间、研究项目、支持案例、分析 notebook 和业务流程案例中。

解决方案：给智能体一个工作空间，其中包含持久目标、状态、产物、参与者、权限、活动记录和终止状态。工作空间应区分来源记录和派生摘要。

权衡：工作空间会增加产品和数据模型复杂度。当工作跨越多个步骤、工具、参与者或会话时，这种复杂度值得承担。

失效边界：如果工作空间变成无人治理的记忆堆，就不安全。旧假设、过期权限和陈旧摘要不能悄悄支配新行动。

模式 2：带证据的上下文约定

问题：当智能体收到的上下文过少、错误、陈旧或来源权限不清时，它会失败。

上下文：代码库文件、来源引用、支持策略、Schema、指标和流程记录都需要上下文边界。

解决方案：定义下一次重要决策所需、可选和排除的信息。当来源类型、日期、版本、负责人和限制影响结果时，把它们记录下来。

权衡：上下文约定会减慢初始设计，但能减少隐藏假设，并让评估更有意义。

失效边界：上下文约定不会让来源变成事实。它只让输入可检查、有边界。

模式 3：权限边界

问题：模型能力可能被误认为系统权限。如果模型能描述某个行动，系统可能意外允许它执行这个行动。

上下文：代码编辑、客户账户变更、数据导出、流程审批和外部消息都需要行动边界。

解决方案：定义权限边界：智能体能看哪些资源、能调用哪些工具、能建议哪些行动、能暂存哪些行动、能提交哪些行动、需要哪些审批、预算多少，以及何时停止。在提示词之外强制执行这个边界。

权衡：较窄权限会降低便利性。较宽权限会扩大错误、提示词注入和高权限组件被借权滥用的影响面。

失效边界：如果下游工具使用的凭据比用户或任务应有范围更宽，或者审批含糊且可复用，权限边界就会失效。

模式 4：验证回路

问题：智能体自报不能证明任务成功。

上下文：编码智能体运行测试，研究智能体检查引用，支持智能体验证案例解决，数据智能体重跑代码，流程智能体核对外部影响。

解决方案：把每个委托回路连接到可观察的成功标准。捕获尝试、工具输出、失败、重试和最终证据。评估结果和追踪记录，而不只是最终文本。

权衡：验证需要时间和基础设施。它也会揭示一些看起来诱人的任务尚不适合自主执行。

失效边界：当智能体选择弱测试、引用无关来源、只验证开心路径或针对可见检查优化时，验证会变成表演。

Anthropic 的智能体评估文章和 OpenAI 的评估 playbook 都支持把运行框架、工具、预算、提示词和环境视为被评估系统的一部分（Anthropic, 2026；OpenAI, 2026）。

模式 5：可审查转换提议

问题：有后果的工作通常要求智能体从分析转向行动。如果这个转换是隐式的，审查者就无法知道自己授权了什么。

上下文：拉取请求、退款、SQL 导出、采购审批、客户消息和案例状态变更。

解决方案：在提交有后果影响之前，把下一步表示为转换提议：目标、操作、行动者、权限、输入、证据、预期影响、可逆性和过期时间。通过确定性控制或负责的行动者接受、拒绝、修订或升级处理该提议。

权衡：提议流程增加摩擦。对于低风险只读回答，它没有必要；但当涉及外部影响、金钱、隐私、访问权限或公开承诺时，它必不可少。

失效边界：如果提议隐藏重要证据、捆绑无关行动，或在底层状态变化后仍然有效，它就不安全。

模式 6：升级处理默认路径

问题：智能体常被优化为继续推进，但负责任的系统需要安全地停止、询问或移交所有权。

上下文：含糊的编码任务、缺乏支持的研究主张、愤怒的支持客户、异常数据和业务例外。

解决方案：运行前定义升级处理触发条件。包括缺失证据、重复失败、高风险行动、策略冲突、身份不确定、不安全工具输出和用户争议。移交应包含可用状态和证据。

权衡：升级处理会降低自动化率。但当智能体离开能力或权限范围时，它能提高安全性、可恢复性和用户信任。

失效边界：如果没有人拥有队列、接收者缺乏证据，或用户体验把升级处理变成被抛弃，升级就会失败。

模式 7：持久状态与恢复

问题：多步骤智能体可能在中断之间丢失已接受进展、外部影响、审批和义务。

上下文：长时间编码任务、研究项目、支持案例、分析产物和业务流程。

解决方案：在模型之外持久化权威状态。记录检查点、已接受转换、外部影响、未知结果、补偿、负责人和终止状态。把摘要视为派生视图，而不是事实来源。

权衡：持久状态需要 Schema 和生命周期设计。没有它，长时间运行的智能体就难以恢复、审计或退役。

失效边界：持久执行机制不能保证业务正确性。存储的状态必须绑定到领域含义和执行边界。

模式 8：运行后学习

问题：随着模型、提示词、工具、数据、用户和环境变化，智能体系统会漂移。一次成功运行不能证明未来可靠。

上下文：失败测试、错误引用、支持重开、数据纠正、流程事件和用户干预。

解决方案：将经过审查的失败和纠正反馈到维护中的评估套件、上下文来源、策略、playbook 和发布门槛。将原始事件与已批准的可复用知识分开。

权衡：学习回路需要所有权和整理。自动吸收每一次纠正可能产生新错误、隐私泄露或策略漂移。

失效边界：当遥测数据变成未审查记忆，或团队只优化最容易捕获的指标时，运行后学习就会失败。

模式如何迁移

模式通过类比迁移，而不是复制粘贴。把模式用于新领域前，先问：

已接受结果是什么？
什么证据证明进展？
可能有哪些外部影响？
谁拥有决策？
涉及哪些数据和权限？
哪些失败可逆？
什么必须升级处理？
哪个已有领域最相似，类比在哪里失效？

例如，代码审查模式可以启发数据分析审查，因为两者都需要可检查产物和可执行检查。但代码测试和 SQL 验证不能互换。支持升级处理模式可以启发业务流程异常处理，因为两者都在转移所有权，但客户可见的同理心和合同义务可能改变产品要求。

不应被提升的内容

一些有吸引力的想法不应成为跨领域模式：

把智能体人格当作架构：角色提示可以帮助风格和任务框架，但不能定义权限、验证或状态。
一个通用工具回路：不同领域的证据、延迟、隐私和可逆性不同。
把置信分数当作信任：只有当置信度针对任务和证据校准时，它才有意义。
把人工审批当作通用控制：没有证据、权限和时间的审批是弱信号。
把基准分数当作部署证明：基准支持在特定条件下比较，不证明本地产品安全。
把记忆当作连续性：连续性需要受治理状态，而不只是被记住的文本。

本手册的判断

设计新的智能体系统时，先从领域案例出发。然后寻找符合相同工作形状的跨领域模式。把模式当作问题清单，而不是跳过本地证据的许可。

只有当一个模式说明了自己的失效边界时，才提升它。可复用模式应让系统在压力下更容易推理。如果它隐藏权限、证据或所有权，它就不是模式，只是词汇。

检查清单

提议的模式是否出现在至少两个具有相似问题结构的领域中？
这个领域的已接受结果是否已定义？
上下文、权限、验证、状态、升级处理和恢复要求是否明确？
模式是否说明自己在哪里不再适用？
供应商例子是否被当作实现证据，而不是通用正确性的证明？
设计是否保留身份、隐私、金钱、安全或法律等领域特定义务？
失败和纠正能否进入维护中的评估或知识源，而不是变成未审查记忆？
审查者是否能理解哪些证据支持该模式，以及哪些仍不确定？

参考文献及其使用方式

OpenAI, “A practical guide to building AI agents” - OpenAI 面向产品与工程的智能体构建文章，用于反复出现的工具、防护栏、移交和人为干预模式。
Anthropic, “Building effective agents” - Anthropic 工程文章，用于工作流与智能体的区别，以及由证据驱动复杂度增加的原则。
Anthropic, “Demystifying evals for AI agents” - 工程文章，用于跨领域的任务、试验、追踪记录、结果、运行框架和评估套件概念。
OpenAI, “A shared playbook for trustworthy third party evaluations” - OpenAI 研究与工程文章，用于完整被测系统记录和主张边界。
NIST AI RMF Playbook - NIST 自愿性风险管理资料，用于上下文、受影响方、监控、响应和治理框架。
OWASP LLM01:2025 Prompt Injection 和 OWASP LLM06:2025 Excessive Agency - OWASP 社区风险条目，用于从输入来源到影响落点的风险和权限边界失效模式。