Agent 的能力不应只按回答质量衡量。进入真实项目后，它还要理解目标、读取环境、调用工具、根据反馈调整动作，并交付可验收的结果。
可以把 Agent 看成一套围绕目标运行的执行系统。模型负责判断下一步，工具负责接触外部环境，工作流和权限规则约束执行过程，测试、页面和原始资料则提供验收证据。任何一环缺失，都可能让任务停在「看似完成」的状态。
Agent 由六部分组成
一个可用的 Agent 可以拆成 Model、Prompt、Tools、Memory、Workflow 和 Guardrails。这是一种便于分析和设计系统的工程拆分，各部分承担不同职责。
| 组成 | 负责什么 | 缺少后的表现 |
| Model | 理解任务、推理并生成下一步行动 | 无法处理开放问题 |
| Prompt | 提供目标、背景、范围和输出要求 | 方向含糊，结果依赖猜测 |
| Tools | 读取文件、搜索资料、调用 API、执行命令 | 只能给出建议，无法改变环境 |
| Memory | 保留偏好、历史决定和任务状态 | 每次从头开始，前后容易不一致 |
| Workflow | 规定读取、执行、检查和交付的顺序 | 步骤随意，容易遗漏验证 |
| Guardrails | 限制权限、操作范围、确认点和停止条件 | 误操作的影响随能力扩大 |
简单任务可能只需要一次模型调用和一个工具，复杂任务则要反复规划、执行和检查。判断系统是否可靠，需要观察它能否从真实环境取得反馈，并据此修正后续行动。
环境反馈可以是搜索结果、命令输出、测试失败、页面截图，也可以是人工意见。缺少这些反馈，模型只能沿着已有上下文继续推测。
Workflow、Automation 和 Agent 解决不同问题
这三个概念描述的是不同维度。
| 方式 | 决策方式 | 更适合的任务 |
| 对话 | 输入一次，回复一次 | 解释、改写、短问答 |
| Workflow | 按预先定义的步骤运行 | 流程稳定、规则明确的任务 |
| Automation | 由时间或事件触发执行 | 定时汇总、监控和通知 |
| Agent | 根据目标和环境反馈动态选择下一步 | 步骤难以提前写死的开放任务 |
它们可以组合使用。例如，Automation 定时启动 Workflow，Workflow 再把需要判断的步骤交给 Agent。选择时应从简单方案开始：单次调用可以完成，就无需增加 Workflow；固定步骤足够，就无需动态规划；只有下一步依赖环境反馈时，才增加 Agent 的自主性。
Anthropic 在 Building Effective AI Agents 中也区分了预定义代码路径的 Workflow 与动态决定过程的 Agent。固定任务通常更适合 Workflow，因为行为、成本和失败路径更容易预测。
好任务始于一份可验收契约
常见 Prompt 模板里的字段可以归为六类：目标、背景、范围、限制、交付物和验收标准。它们共同构成一份任务契约。
目标：最终要得到什么结果
背景：已有资料、当前状态和重要决定
范围：允许读取、修改或调用什么
限制：禁止事项、高风险操作和人工确认点
交付物：文件、代码、报告或可访问页面
验收：用哪些命令、来源或人工检查证明完成「帮我优化项目」把几乎所有判断都留给了 Agent。更可执行的写法是：「只修改文章页的移动端排版，不新增依赖；交付前运行 lint 和 build，并列出需要人工检查的页面。」修改范围和完成条件由此变得明确。
任务描述不必很长，但要减少关键位置的猜测。目标定义方向，限制划定边界，验收标准说明何时停止。缺少停止条件时，Agent 容易扩大范围，或者在结果已经满足要求后继续修改。
可靠执行依赖可回退的循环
一套实用的执行循环包含六步：
读取上下文：检查项目、资料、规则和当前状态。
确认目标：把模糊要求转换为具体交付物和判断标准。
拆分任务：按依赖关系划分可以独立检查的小步骤。
小步执行：限制单次改动范围，并保留修改记录。
检查反馈：读取工具输出、错误、测试和人工意见。
验收停止：目标满足后交付证据，不自行增加任务。
小步执行能够缩短错误定位距离。一次修改 20 个文件后才运行测试，很难判断问题来自哪里；每完成一个模块就检查 diff 和测试，失败时更容易定位，也便于人工在高风险节点介入。
自查与验收承担不同职责。自查仍由执行系统完成，可能延续已有误判；验收需要回到任务之外的证据，例如原始来源、编译器、测试、运行页面或人工决定。
用证据定义「完成」
Agent 的完成声明只代表当前执行已经结束。任务是否完成，要由与任务类型匹配的证据判断。
| 任务 | 有效证据 | 不能单独作为证据 |
| 资料研究 | 原始来源、引用位置、事实与推断的区分 | 一段流畅总结 |
| 文章发布 | 来源核对、链接检查、构建结果、实际页面 | Markdown 文件已经存在 |
| 代码修改 | diff、test、lint、build、运行结果 | 代码看起来合理 |
| 自动化 | 触发记录、权限范围、停止条件、异常处理 | 定时任务已经创建 |
验收标准应在执行前确定。测试失败、链接失效或页面异常都表示任务仍未完成，不能留到交付后再用「建议自行确认」处理。代码任务至少要检查 diff、运行项目规定的验证命令，并查看实际运行效果；研究任务的结论则要能指回第一方来源。
哪些任务不适合交给 Agent
自主执行至少需要明确目标、可观察反馈、可验证结果和受控权限。以下任一条件成立时，都应降低自主性，改用人工判断、只读分析或固定 Workflow：
目标无法具体描述，参与者对「完成」仍有明显分歧；
结果无法独立验证，只能依赖模型评价自己的输出；
错误代价过高，而且操作难以撤销或补偿；
权限无法隔离，完成局部任务必须开放过大的系统范围。
高风险任务仍可以利用 Agent 整理信息、准备变更或执行只读检查。最终判断和不可逆操作仍需由具备责任能力的人完成。
Skill、MCP 和 Memory 各自补什么
当一套做法反复出现，可以将其整理成 Skill。Skill 保存稳定的方法、检查顺序、模板和项目约束，减少重复说明，也让同类任务采用一致的质量标准。
MCP 处理外部连接。按照 Model Context Protocol 官方说明，MCP 是连接 AI 应用与外部数据、工具和 Workflow 的开放标准。它可以减少逐个集成工具的成本，但连接本身不授予无限权限；具体 Server、认证方式和授权范围仍需单独配置。
Memory 负责跨任务连续性，适合保存稳定偏好、术语和已经确认的决定。版本、价格、账号状态、代码分支和线上结果会发生变化，使用前仍需重新验证。长期记忆用于减少重复沟通，不能替代当前事实。
Guardrails 要进入执行过程
幻觉、误删误改、权限过大、隐私泄露、任务跑偏和自动化失控，需要转换为可执行的限制。
| 风险 | 可执行的限制 |
| 编造事实 | 要求第一方来源，区分事实、推断和待确认项 |
| 误删误改 | 破坏性操作前确认，优先使用可恢复方式 |
| 权限过大 | 只开放完成任务所需的最小范围 |
| 隐私泄露 | 敏感资料不交给外部服务，不在输出中回显密钥 |
| 范围扩大 | 明确非目标，交付时检查 diff 和文件清单 |
| 自动化失控 | 设置触发条件、运行上限、停止条件和人工确认点 |
这些限制要落实到工具和流程里。「不自动发送邮件」对应发送前审批；「只修改指定文件」对应目录权限和 diff 检查；「没有变化就不提醒」对应明确的触发条件。
删除数据、付款、发布、发送外部消息、修改生产环境和扩大权限等动作，影响通常超出 Agent 能观察到的上下文。Agent 可以准备操作并说明影响，执行权留在人工确认点之后。
代码任务如何形成可审查交付
代码任务适合 Agent，因为仓库状态、diff、编译器、测试和运行页面都能提供反馈。工作流应从一开始就采集这些证据，最后的修改说明负责汇总结果。
以一个移动端样式问题为例，任务可以先写成：
目标：修复文章表格在 390 px 视口下的横向溢出
范围：只修改文章内容区样式，不改路由，不新增依赖
验收：运行 lint 和 build，并在移动端视口检查目标页面
交付：修改文件、diff 摘要、验证结果和剩余风险
授权：未经确认，不 commit、不 push、不创建 PR随后按可审查顺序推进：
读取 Issue、仓库规则、当前分支和相关样式，确认问题能够复现。
限制修改范围，每完成一小步就检查
git diff -- <path>。运行仓库规定的
test、lint、typecheck或build，再检查真实页面。汇总修改文件、验证输出和未解决事项，让审查者能够复现判断。
获得明确授权后，再执行
commit、push或创建 Pull Request。
GitHub 在这里承担需求记录、变更追踪和人工审查的职责。Issue 提供任务边界，Commit 保存可定位的变更，Pull Request 汇集 diff、检查结果和讨论。任何一项都不能替代实际验证，也不应绕过高风险操作前的授权。
这套过程给出了清晰的责任边界：Agent 负责读取、修改、验证和报告；人负责定义目标、授予权限、审查证据，并决定是否提交、发布或采用结果。
