01 · 如何根据任务需求设计 Agent？ - Agent Design
所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：03 · 如何设计、构建和测试 Agent？ - Development & Practice
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：面对具体任务，如何将模糊需求转化为可验证的任务契约，比较非 Agent 与 Agent 方案，划分模型、程序和人的决策权，完成控制架构、能力配置需求、状态与接口、权限和失败恢复设计，并以明确的实验与验收证据判断方案是否值得实施？
专题导读
本专题（属 Development & Practice）研究面向真实项目的 Agent 工程设计：输入是具有业务背景、资源约束和不确定性的任务需求；输出是可以交给开发者实施、可以交给测试者验证的设计基线。与 「01 · Fundamentals」 中的 「06 · 如何设计一个 Agent？」 不同，前者讨论通用设计原则与架构判断方法，本篇要求这些原则落到具体项目的需求规格、设计决策记录、模块与数据契约、风险控制、测试计划和交付判据。不再重复 A1—A10 的组件定义，也不把某一 SDK 的使用步骤当作设计方法。
贯穿案例为“技术研究助理 Agent”：接收研究委托，检索和阅读材料，形成证据记录，比较技术路线，输出可核验的研究报告。案例包含两种候选方案：确定性检索—写作工作流，以及能够根据证据缺口动态选择检索与阅读行动的 Agent。我们将以可比较的验收指标和成本边界，而不是以“更智能”作为选型理由。
本篇提供一套可直接复用的工程设计流程、数据契约示例、状态机、失败场景矩阵、实验方案与设计审查清单。示例数值和接口为参考设计假设，并非通行行业标准或已在生产环境验证的指标。文中区分公开文献所支持的技术思想与本篇提出的工程设计建议。
一、研究对象与设计交付物
1.1 从需求到可验证系统的五层映射
Agent 设计并非先选择框架、编写角色提示词或堆叠工具，而是建立如下可追溯链条：
业务问题与使用场景
→ 任务契约（输入、输出、边界、成功条件）
→ 方案选择（程序 / 工作流 / 模型辅助 / 动态 Agent）
→ 设计契约（控制权、模块、状态、接口、权限、失败语义）
→ 验证契约（数据集、对照组、指标、阈值、停止与回退规则）任何一层都必须回答“如何知道它成立”。例如，“报告可靠”不能直接成为验收条件；需要进一步规定：关键事实可追溯到原始资料、引用与论点一一对应、重要矛盾被明确披露，并由独立评测流程抽样核对。对尚不能自动判定的质量维度，应定义人工评审量表与争议处理办法。
1.2 本专题的最小交付物集合
| 交付物 | 必须回答的问题 | 下游使用者 |
|---|---|---|
| 需求与任务契约 | 为谁解决什么问题；成功、失败、拒绝、暂停分别是什么 | 设计、开发、测试 |
| 方案比较与 ADR | 为什么采用该架构；替代方案为何不选；什么证据会推翻决定 | 架构评审 |
| 组件与控制架构图 | 哪些判断交给模型，哪些交给程序，哪些需要人批准 | 开发 |
| 输入输出及工具契约 | 具体数据结构、字段校验、错误类型、副作用与超时 | 开发、集成测试 |
| 状态与生命周期设计 | 哪些状态必须保存；如何终止、恢复、去重 | 开发、运行环境 |
| 权限与风险矩阵 | 谁可执行什么操作；信任边界和审批条件 | 安全、开发 |
| 评测与验收计划 | 采用哪些任务集、对照组、指标、阈值与复核方式 | 测试、项目负责人 |
设计的完成标准不是“图已经画好”，而是开发与测试人员能依据上述契约独立开展工作，关键歧义有明确记录，重大风险有处理策略。
1.3 与其他专题的边界
Fundamentals 的 Agent Design 侧重一般性的架构选择原理；本篇侧重项目化的设计产出和证据化决策。下一专题 Configuration 研究配置的表达、加载、版本和变更；Implementation 研究具体代码、接口集成和运行逻辑；Testing 研究评测实施与统计分析；Case Studies 研究完整项目的决策与结果。Agent System 则深入研究可复用 Runtime、任务调度、持久化、并发和系统级恢复。本篇必须提出这些方面的需求与接口，但不代替相邻专题实现它们。
二、从真实任务建立需求规格
2.1 先定义使用者、环境与任务边界
需求访谈至少要识别：使用者及其专业程度、任务触发方式、输入来源与数据敏感度、期望产物、任务频率、响应时限、允许的外部系统、人工介入条件、可接受的失败代价。对于高风险领域，需额外评估法律、行业规范和专业审核要求；不能把自然语言中的“帮我处理”视为对所有外部操作的授权。
研究助理案例的需求示例：
- 使用者：需要技术方案比较的研究者或开发者。
- 输入：研究主题、问题清单、资料范围、报告格式、截止时间与预算。
- 输出：结构化研究报告、来源清单、证据—主张对应关系、未解决问题。
- 允许行动：搜索公开资料、读取授权文档、生成本地草稿。
- 受限行动：不得未经确认向外部平台发布、发送邮件或覆盖已有文件。
- 失败行为：关键证据不足时说明不足；工具连续失败或预算耗尽时中止并输出可恢复的进度记录。
2.2 把“质量好”拆成可观察指标
需求至少划分为四类：功能正确性（是否完成任务）、内容质量（是否准确且有证据）、运行行为（是否越权、循环、误用工具）、资源与体验（时间、成本、人工工作量）。验收指标必须定义计算单位和采样方式，避免“准确率 90%”这种没有分母与判定规则的数字。
| 需求 | 可操作的判定方法 | 常见误区 |
|---|---|---|
| 来源可追溯 | 抽样核对每条关键主张是否对应可访问且支持该主张的来源 | 只检查是否出现 URL |
| 研究覆盖充分 | 按预先定义的问题清单逐项评分，记录缺口 | 用报告字数代替覆盖度 |
| 不确定性表达 | 在证据不足或来源冲突的样本中检查是否适当保留判断 | 把“语气自信”当正确 |
| 任务成功 | 按固定任务集和评分规则计算完成比例 | 只展示最成功的一次 |
| 运行边界 | 检查全部工具调用是否经过授权和参数校验 | 只看最终文本是否合规 |
| 资源效率 | 统计每个成功任务的耗时、调用量、费用 | 只看单次模型调用成本 |
2.3 任务契约示例
task_id: research-001
objective: 比较三种 Agent 记忆架构并形成有证据的报告
inputs:
questions: [机制差异, 工程成本, 适用条件]
source_scope: public_and_authorized
outputs:
report: markdown
evidence_index: structured_records
unresolved_questions: list
constraints:
max_tool_calls: 24
deadline_seconds: 600
allow_external_publish: false
completion:
require_all_questions_addressed: true
require_evidence_for_key_claims: true
permit_partial_with_explicit_gaps: true此处 max_tool_calls: 24、deadline_seconds: 600 仅为实验设计占位值，必须通过目标任务分布的基线测量再确定。completion 也不能直接依靠模型自行声明通过，而应由可验证规则和必要的人工审查共同判定。
三、选择 Agent 之前：建立最简单可行基线
3.1 四种可比较方案
| 方案 | 运行时路径由谁决定 | 适用条件 | 主要风险 |
|---|---|---|---|
| 确定性程序 | 代码与规则 | 输入结构化、步骤稳定 | 规则覆盖不足 |
| 固定工作流 | 预设流程图及分支 | 已知步骤、多阶段处理 | 难适应未知路径 |
| 模型辅助工作流 | 程序控制流程，模型处理局部语义 | 摘要、分类、抽取、有限判断 | 模型局部错误传播 |
| 动态 Agent | 模型基于观察提出后续行动，运行时校验执行 | 证据与路径未知、反馈驱动探索 | 成本波动、复合错误、循环与越权 |
这种分类用于比较控制权，并不表示四类技术互斥。动态 Agent 内部可以执行固定工作流，固定工作流也可以包含模型判断。Anthropic 的 Building Effective Agents 对 workflows 与 agents 的区分强调路径控制方式，并建议优先使用最简单、足以完成任务的方案；本篇将其作为选型依据之一，而非不经实验的结论。
3.2 决策所需的任务特征
至少评估六个维度：路径是否可预知、信息是否需要迭代发现、下一步是否依赖环境反馈、外部操作是否具有副作用、错误是否可逆、是否能够构建可判定的完成条件。额外考虑任务量、成本上限、响应时间与维护能力。
可使用如下决策过程：先实现最小非 Agent 基线；在代表性任务上测量质量与成本；分析失败是否确实来自“缺乏动态行动选择”，而不是检索质量、提示词或数据处理不足；仅在动态决策可能带来可测增益时，引入 Agent 并进行对照实验。
3.3 方案选择的决策记录（ADR）
ADR-001 研究助理的执行控制方式
背景：固定检索轮次在证据稀缺主题上可能漏掉关键资料。
候选：A 固定检索-写作；B 模型辅助工作流；C 动态检索 Agent。
假设：C 在证据缺口较大的任务上提高有效覆盖率。
代价：C 的调用次数、延迟、执行路径波动更大。
决定：先部署 B 作为基线；在受限工具和预算内试验 C。
接受条件：C 在预先划分的测试集上提升质量，且不突破成本/安全约束。
回退条件：质量提升不稳定，或超时、错误调用显著增加。
状态：待实验验证。ADR 应记录决策日期、负责人、证据和待验证假设。它是技术选择的可追溯记录，不是给既定方案寻找理由的说明书。
四、设计决策权：模型、程序与人如何分工
4.1 控制权是核心架构变量
模型擅长对非结构化信息进行语义判断、提出候选计划和解释证据，但其输出不能自动视为可信指令。确定性程序适合参数校验、状态转换、预算计数、权限检查和可形式化的完成条件；人负责高风险授权、难以自动裁定的质量审核与责任决策。
| 行为 | 模型 | 程序/可信运行时 | 人 |
|---|---|---|---|
| 识别研究问题与证据缺口 | 提议与分析 | 校验结构和范围 | 可复核 |
| 选择下一次检索 | 提议工具与参数 | 白名单、参数、预算检查后执行 | 通常无需介入 |
| 读取来源 | 摘要、判断相关性 | 控制资源访问、保存来源标识 | 必要时复核 |
| 引用与结论形成 | 生成候选主张 | 检查引用结构、来源可访问性 | 对关键主张抽查 |
| 发布报告/外发信息 | 提议 | 阻断未授权操作 | 明确批准 |
| 任务结束 | 提议已完成 | 校验终止条件和预算 | 可最终验收 |
核心不变量：模型产生的是行动提议；工具执行必须经过独立的参数、权限和状态校验。系统提示词、角色描述和模型自我审查不能代替执行边界。
4.2 建议采用的最小控制结构
用户任务
↓
Task Intake / Contract Validator
↓
State Builder ────────────────┐
↓ │
Model / Decision Adapter │
↓ │
Action Proposal │
↓ │
Schema Validator → Policy Gate → Tool Executor
↓ │
Normalized Observation │
↓ │
State Update ────────────────┘
↓
Completion Validator → 输出 / 继续 / 暂停 / 失败这张图描述的是逻辑职责，不要求每个框都部署为独立服务。初期可以在单进程中实现；当并发、持久化和调度需求增长时，再将相关职责下沉到 Agent System。
4.3 规划方式的选择
对于短任务，可采用单步“观察—选择—执行—反馈”；对于长任务，可使用显式计划、子任务状态和周期性重规划；对于强约束任务，可将固定流程作为外层控制，仅在局部节点允许模型决策。选择时应比较计划稳定性、反馈延迟、任务可分解性和错误恢复成本。自然语言计划不是可执行计划：需要将其约束到允许动作、前置条件和可观察状态变化。
五、能力需求设计：从 A1—A10 中选择必要能力
Internal Architecture 的十个维度是分析坐标，不是要求每个 Agent 都配置十个独立模块。本篇应从需求推导能力，而非从组件清单反推需求。
| 能力维度 | 本案例的设计问题 | 是否需要及判断 |
|---|---|---|
| A1 Identity & Role | 研究助理职责与交付边界是什么 | 需要清晰职责契约 |
| A2 Model | 需要怎样的工具调用、长文本和结构化输出能力 | 通过候选模型实验选型 |
| A3 Instructions | 如何表达研究标准、输出结构与拒绝条件 | 需要可版本化指令 |
| A4 Context | 哪些资料进入当前模型输入 | 需要选择、裁剪与溯源策略 |
| A5 Memory | 是否跨任务保留偏好或研究经验 | 首版可不引入长期记忆 |
| A6 Knowledge | 如何检索、筛选、核对外部资料 | 核心能力 |
| A7 Tools | 需要哪些检索、读取、写入接口 | 核心能力，严格限定副作用 |
| A8 Skills | 是否复用文献筛选和报告检查流程 | 需求稳定后再封装 |
| A9 Planning & Reasoning | 何时追加检索、改写查询、停止 | 核心动态决策能力 |
| A10 Permissions & Constraints | 谁可访问、写入、发布及消耗预算 | 必须独立执行 |
能力选择应遵循“需求—机制—接口—测试”映射。新增记忆或技能必须对应明确的任务失败模式与验证收益；不能因为框架提供某功能就默认启用。
六、定义可实施的接口与数据契约
6.1 关键数据实体
一个最小研究 Agent 可以使用以下逻辑实体：
TaskSpec(task_id, objective, questions, constraints, acceptance)
Source(source_id, uri, title, retrieved_at, content_hash)
Evidence(evidence_id, source_id, excerpt, claim_scope, confidence_note)
ActionProposal(call_id, action_type, arguments, rationale)
ToolObservation(call_id, status, payload, error_code, side_effect_ref)
RunState(run_id, phase, open_questions, evidence_ids, budget_used, version)
Report(report_id, claims, citations, unresolved_questions, status)content_hash 可用于发现资料版本变化，但不能证明内容真实性；confidence_note 是对证据限制的说明，不能把模型自报置信度当成经过校准的概率。数据结构应明确必填字段、类型、标识符作用域、序列化规则与版本兼容策略。
6.2 工具契约示例
{
"name": "read_source",
"input": {"source_id": "src-014"},
"output": {
"source_id": "src-014",
"content": "...",
"retrieved_at": "2026-10-28T08:00:00Z",
"content_hash": "sha256:..."
},
"errors": ["NOT_FOUND", "ACCESS_DENIED", "TIMEOUT", "RATE_LIMITED"],
"side_effect": "read_only"
}该示例是接口设计草案，不是某一 SDK 的实际请求格式。真实实现还需要明确超时单位、重试策略、响应大小上限、来源内容的信任级别、错误是否可重试以及对返回数据的清洗方式。对具有外部副作用的写入工具，应另行定义幂等键、审批绑定、提交状态和结果核对方法。
6.3 状态与终止条件
CREATED → VALIDATED → RUNNING ──→ COMPLETED
│ │
│ ├──→ WAITING_APPROVAL → RUNNING
│ ├──→ PAUSED → RUNNING
│ ├──→ PARTIAL
│ └──→ FAILED
└──────→ CANCELLED建议将任务状态与一次工具调用状态分开。任务 COMPLETED 需要满足验收器条件，而不是仅依赖模型生成“已完成”；PARTIAL 应明确未满足的要求；FAILED 应记录失败原因及是否可重试。每次恢复都需要重新检查当前权限、预算和外部环境状态，不能默认沿用旧的授权结果。
七、非功能需求与风险设计
7.1 安全与信任边界
外部网页、文件和工具返回值属于低信任输入。它们可能包含指令式文本，但不能改变系统的工具权限、任务目标或审批规则。应将来源内容作为数据进入模型上下文，并在可信执行层限制工具调用。对于外部文档中的提示注入、跨租户访问、凭证泄漏、任意 URL 读取和未经授权发布，应设置针对性的威胁测试。
7.2 可靠性与失败语义
| 失败情形 | 设计响应 | 不应发生的行为 |
|---|---|---|
| 搜索无结果 | 改写查询或声明证据缺口，受重试预算约束 | 无限重复相同检索 |
| 来源内容相互矛盾 | 保留冲突与来源差异，必要时请求复核 | 隐藏冲突直接生成确定结论 |
| 工具超时 | 区分可安全重试与执行状态未知 | 对非幂等操作盲目重试 |
| 模型返回无效工具参数 | 结构校验失败，反馈有限纠错机会 | 直接执行未校验参数 |
| 预算耗尽 | 结束或部分交付，保留进度 | 悄悄超额执行 |
| 人工审批未到 | 挂起并保留审批请求标识 | 默认批准或更换参数后复用审批 |
| 来源被更新或删除 | 标注版本差异，重新验证依赖主张 | 继续把旧内容视为最新事实 |
7.3 成本与性能设计
需要估算模型调用、工具调用、检索与读取、上下文长度、重试、人工复核和存储等成本。关注每个成功任务的总成本，而不是单次请求费用。性能设计应覆盖端到端延迟的中位数及尾部表现、工具限流、最大步骤数、取消传播与超时分配。没有实测数据时，预算阈值应作为待验证假设，而非既定 SLA。
八、从设计进入验证：对照实验与验收
8.1 先定义实验问题
研究助理案例的核心假设是：在研究路径不可预知、证据需要多轮发现的任务中，动态 Agent 相比模型辅助工作流能够改善证据覆盖与最终报告质量；但可能付出更高的延迟和成本。
对照组 A：固定检索轮次 + 模型分析与写作。实验组 B：允许在预算内根据证据缺口动态检索。应尽量保持模型版本、工具集合、检索数据源、输出格式和评分规则一致，避免将模型升级带来的收益误判为 Agent 架构的收益。
8.2 任务集与评测设计
任务集至少覆盖：资料充分的常规主题、资料稀缺主题、来源冲突主题、模糊研究目标、工具错误与超时、恶意来源内容、预算边界。按难度和风险分层，在设计阶段固定一部分保留测试集，避免不断针对测试样本调参造成评估污染。
| 指标 | 定义与测量方式 | 主要局限 |
|---|---|---|
| 任务完成率 | 满足预先定义验收条件的任务数 / 有效任务数 | 依赖验收规则质量 |
| 证据支持率 | 抽样关键主张中被来源实际支持的比例 | 需要人工或高质量独立裁定 |
| 问题覆盖率 | 已充分回答的预设研究问题数 / 问题总数 | “充分”需明确量表 |
| 越权执行次数 | 实际执行且违反权限契约的操作次数 | 零观测不代表不存在风险 |
| 恢复成功率 | 预定义可恢复故障中最终完成的比例 | 依赖故障注入覆盖面 |
| 成功任务成本 | 总实验成本 / 成功任务数 | 需同时报告失败任务成本 |
| 端到端延迟 | 从任务提交到最终状态的耗时分布 | 受工具网络波动影响 |
不宜只用 LLM-as-a-Judge 作为唯一真值。可采用规则检查、人工盲评、引用核对和模型辅助评分的组合，并对评审一致性、偏差与争议样本进行记录。
8.3 验收与回退门槛
建议在开发前明确：哪些安全条件属于不可妥协的硬门槛，哪些质量指标允许通过权衡优化，哪些成本或延迟超限会触发回退。阈值应由业务需求、风险评估和基线实验确定；本篇不提供脱离场景的通用合格百分比。
例如，可设定“所有发布行为必须具备绑定具体内容与目标的有效人工授权”为硬约束；“报告质量相较基线有可重复提升”为效果要求；“单位成功任务成本不得超过项目预算”为经济约束。若实验组只在少数示例中表现更好、整体成本显著增加，则应优先维持较简单的架构。
九、工程设计流程：九步实施法
以下九步是本篇归纳的参考工程流程，不是行业统一标准。
- 明确任务场景：识别用户、目标、输入、输出、环境、频率与风险。
- 形成任务契约：定义成功、失败、部分交付、权限、资源与终止条件。
- 建立非 Agent 基线：先构建最简单可行方案，获得质量与成本参考。
- 识别动态决策点：区分确定性步骤、模型语义判断和需人批准的操作。
- 选择控制架构：确定执行循环、规划方式、状态管理和反馈路径。
- 推导能力需求：从任务失败模式选择模型、知识、工具、记忆和技能等机制。
- 定义接口与安全边界：明确数据契约、授权、审批、副作用、错误与恢复。
- 制定实验和验收计划：设计任务集、对照组、评测指标、预算及回退规则。
- 评审并冻结设计基线：输出 ADR、接口草案、风险清单和实施优先级，进入 Configuration 与 Implementation；允许基于测试证据变更，但必须记录原因。
这九步并非一次性瀑布流程。原型验证可能推翻第 4 步的假设，测试结果也可能要求回到第 2 步重新定义成功标准。设计的核心是假设可检验、决策可追溯、变更可解释。
十、完整设计实例：研究助理 Agent 的首版方案
10.1 设计结论
首版采用“确定性外层控制 + 受限动态研究决策”的混合架构。模型可以提出检索词、选择阅读来源、判断证据缺口、组织报告，但不得自行扩大工具权限、绕过预算、发布报告或宣布未经验证的成功。对于格式校验、引用存在性检查、工具参数验证和预算计数，优先使用确定性代码。
10.2 最小可交付范围（MVP）
首版仅支持单次技术研究任务；输入为主题、问题清单与来源范围；工具为 search、read_source、save_draft；输出为 Markdown 报告和结构化证据索引；任务状态为单次运行范围；不引入跨任务长期记忆、自动发布、多 Agent 协作或复杂技能市场。这样可以减少无法归因的变量，使初期评测更清晰。
10.3 一次典型运行的控制轨迹
用户提交研究任务
→ 验证任务契约和来源访问范围
→ 模型提出初始检索计划
→ 运行时验证 search 参数与预算
→ 执行检索并记录来源标识
→ 模型选择 read_source
→ 读取材料、生成候选证据记录
→ 证据检查：问题 2 缺少可靠资料
→ 模型提出补充检索（受剩余预算限制）
→ 重新评估证据覆盖与冲突
→ 生成草稿及主张—来源索引
→ 结构检查与抽样事实复核
→ 满足验收则完成；否则部分交付或失败该轨迹说明设计意图，不代表实际运行结果。是否能够稳定识别证据缺口、减少错误引用，仍需要在 Implementation 和 Testing 中通过真实模型与工具验证。
10.4 关键取舍
为什么不一开始引入长期记忆？ 当前任务的成功主要依赖单次运行中的证据管理；跨任务记忆会增加数据治理、污染和评测归因难度。只有当重复任务实测表明记忆带来可测收益时再引入。
为什么不允许 Agent 直接发布？ 发布具有外部副作用，且报告质量可能需要人工负责；模型生成“可以发布”不能代替审批。
为什么需要证据索引？ 它把研究结论与来源建立结构化联系，支持独立核对、回归评测和来源失效后的影响分析。仅在报告末尾附上链接列表不足以保证可追溯。
为什么先做基线？ 没有固定工作流或模型辅助工作流的质量—成本基线，无法证明动态 Agent 的复杂性值得承担。
十一、设计评审：常见反例与检查清单
11.1 典型反例
- 角色描述代替任务设计：只写“你是资深研究员”，没有输入输出、验收或错误语义。
- 功能堆叠代替能力推导：默认加入记忆、技能、多个模型和大量工具，却无法说明具体收益。
- 模型文本代替可信控制：让模型自己判断权限、预算和是否可以发布。
- 只设计成功路径：没有超时、冲突来源、部分交付、取消和恢复方案。
- 演示成功代替系统验证：单个精心挑选的任务成功，就宣称架构优于基线。
- 混淆逻辑架构与部署架构：为每个逻辑模块单独部署服务，提前引入不必要的分布式复杂性。
11.2 进入开发前的设计检查
| 检查问题 | 合格证据 |
|---|---|
| 任务边界是否清晰 | 任务契约及非目标列表 |
| 是否比较过简单方案 | 基线设计与 ADR |
| 模型的决策权限是否明确 | 行动类型、允许范围与可信执行点 |
| 是否定义输入输出与工具协议 | Schema、错误码、副作用语义 |
| 状态和完成条件是否可验证 | 状态图、终止判据与失败状态 |
| 是否考虑高风险行动 | 权限矩阵、审批与审计要求 |
| 是否设计失败恢复 | 故障矩阵、重试与幂等策略 |
| 是否能够验证质量收益 | 对照实验、数据集、评分量表 |
| 是否有成本与性能边界 | 预算假设、测量与回退条件 |
| 是否记录待验证假设 | ADR、风险与开放问题列表 |
十二、技术研究依据与进一步阅读
以下资料用于支持本篇的技术思想与设计方法，不是本篇具体工程契约、状态图或阈值的直接来源。链接为已知公开资料入口；本次撰写未逐页在线核验最新版本，也未执行真实 Agent 对照实验。
- Anthropic, Building Effective Agents（2024）。讨论 workflows 与 agents 的区分、常见编排模式，以及从简单方案开始的工程建议。anthropic.com/engineering/building-effective-agents
- OpenAI, A Practical Guide to Building Agents（2025）。从模型、工具、指令、护栏和工作流编排讨论 Agent 设计。a-practical-guide-to-building-agents.pdf
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models（2022/2023）。提出交替生成推理与行动、使用环境反馈推进任务的研究路径。arXiv:2210.03629
- Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models（2023）。展示自动课程、技能库与迭代反馈在开放环境任务中的组合，适合讨论复杂能力何时值得引入。arXiv:2305.16291
- NIST, AI Risk Management Framework 1.0（2023）。提供风险治理、测量和管理的通用框架；不是专门针对 Agent 的执行协议。nist.gov/itl/ai-risk-management-framework
- ISO/IEC/IEEE 29148:2018, Requirements Engineering。可用于参考需求规格、可追溯性与验证要求；本篇的任务契约格式并非该标准的原样复现。
资料与验证声明
本文关于模型—程序—人控制权划分、任务契约字段、九步流程、状态机和评测方案，是结合既有研究思想提出的工程参考模型。本篇未宣称完成真实 SDK 兼容性测试、生产级安全审计或实测任务成功率。后续进入 Agent Configuration、Implementation 与 Testing 后，应逐步将设计假设转化为可执行代码、可复现数据和测试记录。
十三、专题总结与下一步
面向真实任务设计 Agent 的本质，是把用户期望转化为一组可以实施和验证的工程决策：明确任务契约，证明动态决策的必要性，限定模型行动权限，选择最小充分能力，定义状态和接口，预设失败行为，并建立对照实验和回退标准。
本篇的最终交付不是“一个看起来完整的 Agent 架构图”，而是一套可追溯、可实施、可测试的设计基线。下一专题 「02 · Agent Configuration」 将进一步研究如何将这些设计要求编码为可版本化、可校验、可加载的模型、指令、工具、能力和运行配置；随后在 Implementation 中实现，在 Testing 中验证，并通过 Case Studies 形成可复用的工程经验。