AI代理与工作流的本质区别：从Anthropic指南看工程落地范式

简介：本资源是Anthropic官方发布的《构建高效的 Agents 指南》中文全译版PDF，面向AI工程师、LLM应用开发者及Agent系统架构师，聚焦解决实际工作流中人力消耗大、重复操作多、自动化落地难等核心痛点。报告颠覆“越复杂越强大”的惯性认知，系统阐述“Less is More”设计哲学——强调从真实业务场景出发，以简单、可组合的模块化方式构建高价值Agent系统，而非堆砌框架或炫技式技术集成。资源为单文件PDF（878KB），内容完整覆盖Agent本质定义、工作流与Agent架构差异、框架选型建议、典型实现模式及商业ROI评估逻辑，附有词源辨析、行业案例对比与生产级实践指南。目前已有450人学习下载，适合希望摆脱概念炒作、扎实掌握高效Agent设计方法论的中高级开发者快速建立系统性认知并指导工程落地。

1. Anthropic 官方《构建高效的 Agents 指南》中文全译发布：一场对“复杂即强大”认知的系统性祛魅

这不是一份普通的技术文档翻译，而是一次行业级的方法论校准。当整个生态正狂热追逐多智能体编排、自主推理循环、超长记忆上下文和嵌套式工具调用时，Anthropic 团队用一份来自数十个真实生产环境的合作实证报告，给出了一个冷静到近乎反直觉的结论：最成功的 AI 代理（AI Agents）系统，几乎从不依赖复杂框架，而是由极简、可组合、边界清晰的模块动态拼接而成。这份指南不是教你怎么“造神”，而是告诉你如何在 LLM 能力边界内，用最少的抽象、最透明的路径、最克制的干预，让一个数字代理人稳稳落地、持续交付价值。它直指当前实践中的三大幻觉——把“能调用多个工具”等同于“具备代理能力”，把“流程分支多”误读为“智能化程度高”，把“框架封装深”错认为“工程成熟度强”。更关键的是，它首次将“代理”（Agent）与“工作流”（Workflow）在架构层面明确划界：前者是 LLM 动态规划并自主驱动执行路径的系统；后者是代码预定义、步骤固定、LLM 仅作为环节执行器的编排结构。这种区分不是语义游戏，而是决定你该投入 200 行代码还是 2000 行调试时间的关键分水岭。今天发布的中文全译版，正是帮你绕过概念炒作、直抵 Anthropic 一线团队血泪经验的核心入口。

2. 从“代理”定义开始的范式重置：为什么必须放弃“智能体”这个译法？

2.1 词源锚定：Agent 的本质是“代表行动”，而非“智能涌现”

理解一切技术实践的前提，是回归概念本源。“Agent”一词并非技术新造，它根植于拉丁语agere（行动、执行、推动），在英语中始终承载着“代表他人行事”的核心契约关系。FBI Agent 代表国家执法，Travel Agent 代表旅客订票，Insurance Agent 代表公司签约——它们的合法性、可信度与价值，全部建立在“被授权”“有边界”“可追责”这三个基点之上。将 AI Agent 翻译为“智能体”，看似高大上，实则抽空了这层社会性契约：一个“体”可以是黑匣子、可以是不可控的涌现现象、可以是实验室里的炫技玩具；而一个“代理人”，必须有明确的委托目标、可解释的行动逻辑、可审计的决策痕迹、可中断的执行权限。Anthropic 在报告开篇就强调：“真正的 AI Agents 应该是帮你解决实际问题的数字助手，而不是概念上的哗众取宠。” 这句话的重量，正在于它把技术讨论拉回了商业与组织语境——你雇一个代理人，是为了让他替你跑腿、谈判、填表，不是为了看他跳一支算法芭蕾。

2.2 架构分野：工作流（Workflow）与代理（Agent）不是程度差异，而是范式差异

Anthropic 明确划出了一条硬线：

• 工作流（Workflow）是“代码路径预定义”的系统。LLM 在每个环节只负责处理输入、生成输出，其角色是确定性流水线中的一个函数。例如：“用户提问 → LLM 分类 → 路由至退款/技术支持子流 → LLM 生成回复 → 调用 API 执行退款”。整个路径在部署前已写死，LLM 无权增删步骤、无法动态选择工具组合、不能因某次失败而重构计划。它的优势是可预测、易测试、成本低、延迟稳。
• 代理（Agent）是“LLM 动态规划并驱动”的系统。它接收初始指令后，自行拆解任务、评估进展、选择工具、处理反馈、修正错误，甚至在卡壳时主动向人类请求澄清。它的核心特征是非确定性、自适应、状态感知、带反馈循环。例如：“用户说‘修复登录页 500 错误’ → Agent 查看日志 → 发现 Nginx 配置异常 → 编辑 config 文件 → 重启服务 → 验证 HTTP 状态码 → 失败 → 检查进程 → 发现端口冲突 → 修改端口 → 再次验证 → 成功”。整个过程没有预设脚本，每一步都由 LLM 基于实时环境反馈做出判断。

提示：混淆二者是项目失败的第一诱因。当你发现团队在争论“这个功能该用 LangGraph 还是自己写 loop”，却没人能说清“如果 LLM 在第三步突然决定跳过工具 A 改用工具 B，现有流程是否支持？”——那你大概率已经把工作流当成了代理来设计。

2.3 商业校验：三个不可妥协的落地标尺

Anthropic 提出的代理价值判断，彻底剥离了技术浪漫主义，回归组织理性：

1. 痛点驱动（Pain-point First）：必须从现有工作流中识别出“人力黑洞”环节——那些让员工反复抱怨“每天花两小时干这个，烦死了”的重复性、规则性、低创造性任务。不是“我们有 LLM，所以要造个 Agent”，而是“销售团队每周手动整理 200 份客户反馈，耗时 16 小时，错误率 12%，这里必须上 Agent”。
2. 接管而非创造（Take Over, Not Invent）：Agent 的使命是自动化已存在且已被验证有价值的手动流程。它不负责发明新业务，只负责把人从旧流程里解放出来。强行给全自动空调贴“AI Agent”标签，就像给 Excel 公式加个“智能决策引擎”前缀——技术上成立，商业上荒谬。
3. ROI 可量化（Return on Investment）：必须能回答三个问题：自动化后节省多少 FTE（全职人力）？单位任务处理时间下降多少百分比？错误率降低带来多少客诉/返工成本节约？Anthropic 特别指出，客户支持领域已有公司采用“按成功解决案例收费”模式，这背后是对 Agent 效能的绝对信心——没有可量化的 ROI，所有技术投入都是成本中心。

3. 工作流：五种被验证的高效模式及其适用边界的硬核拆解

3.1 提示链（Prompt Chaining）：用延迟换精度的确定性流水线

提示链的本质，是将一个复杂任务强制分解为原子化、低歧义、高可控的子任务序列，每个子任务由一次 LLM 调用独立完成。其核心价值不在于“让 LLM 更聪明”，而在于“让每个 LLM 调用更专注”。

# 示例：营销文案生成与多语言适配工作流 def marketing_workflow(user_input): # Step 1: 生成核心文案（聚焦创意，不考虑语言） draft = llm_call( system="你是一位资深品牌文案专家。根据产品卖点生成300字以内高转化文案。", user=user_input ) # Step 2: 语法与合规性检查（程序化 gate） if not is_grammar_valid(draft) or contains_prohibited_terms(draft): raise ValueError("文案未通过基础校验") # Step 3: 多语言翻译（聚焦语言转换，不参与创意） translations = {} for lang in ["zh", "ja", "ko"]: translations[lang] = llm_call( system=f"将以下文案精准翻译为{lang}，保持营销语气和文化适配。", user=draft ) return {"original": draft, "translations": translations}

关键参数说明：

• is_grammar_valid()和contains_prohibited_terms()是轻量级程序化检查（正则/关键词库），充当“质量闸门”（gate），确保错误不向下传递；
• 每个llm_call的 system prompt 高度特化，避免 LLM 在单次调用中同时处理创意+语法+翻译三重负担；
• 适用边界：任务可被清晰切分为逻辑递进、无回溯依赖的步骤（如“写大纲→校验大纲→写正文→校验正文”）。当某步输出需根据后续步骤反馈动态调整时（如翻译后发现原文有歧义需重写），提示链即失效。

3.2 路由（Routing）：用分类隔离实现性能与成本的双重优化

路由不是简单的“if-else”，而是构建领域专用通道的策略。其威力在于：让不同类别的输入，进入为其量身定制的“最小可行工作流”，从而规避“用大模型解决小问题”的资源浪费，也防止“用小模型硬扛复杂问题”的效果坍塌。

实战陷阱：路由分类器本身必须足够鲁棒。Anthropic 观察到，客户常犯的错误是用单一 LLM 调用做粗粒度分类（如“这是什么类型问题？”），导致 15% 的请求被错误分流。更可靠的做法是：组合信号——先用轻量规则（关键词、正则）快速过滤 60% 明确请求，剩余部分再用小型微调模型（如 LoRA 微调的 Haiku）做细粒度分类，最后对高置信度阈值（>0.95）才触发路由。这比依赖单一大模型“灵光一闪”稳定得多。

3.3 并行化（Parallelization）：分段与投票的两种反脆弱设计

并行化不是为了“快”，而是为了对抗 LLM 的不确定性。它提供两种截然不同的容错路径：

• 分段（Segmentation）：将任务空间物理隔离，让不同 LLM 实例处理互不干扰的子域。典型场景是安全防护：一个实例专注生成用户响应，另一个实例同步扫描该响应是否含 PII（个人身份信息）或违规内容。两者结果通过程序逻辑合并（如“响应生成成功 AND 安全扫描通过 → 返回；否则拦截”）。这比让单个 LLM 同时思考“怎么写好”和“怎么写安全”更可靠——因为后者极易顾此失彼。
• 投票（Voting）：对同一任务启动多视角探索，通过聚合结果提升置信度。例如代码漏洞审查：

  # 启动 3 个独立审查实例，使用不同提示侧重 prompts = [ "请从内存安全角度检查此代码", "请从输入验证角度检查此代码", "请从权限控制角度检查此代码" ] findings = [llm_call(system=p, user=code) for p in prompts] # 聚合：仅当 ≥2 个实例标记同一行存在风险时，才触发告警

关键洞察：并行化的效果高度依赖“视角分离度”。Anthropic 测试发现，若 3 个投票提示仅在末尾加“请从X角度检查”，而主体完全相同，投票效果几乎为零——因为 LLM 会复用同一思维路径。真正有效的提示差异，必须改变问题的底层建模方式（如“列出所有可能的攻击向量” vs “假设你是黑客，写出 3 种利用此函数的 PoC”）。

3.4 编排者-执行者（Orchestrator-Workers）：为不可预测性预留的弹性架构

这是最接近“经典 Agent”形态的工作流，但 Anthropic 强调：它不是代理的替代品，而是代理的简化前置。编排者（Orchestrator）LLM 不直接执行，只做三件事：1）解析用户指令，2）动态生成子任务列表（如“查订单状态→调取物流信息→生成预计送达时间→检查库存余量”），3）将子任务分发给执行者（Workers）LLM 并汇总结果。执行者 LLM 是无状态、无记忆的“工具调用器”，只负责完成分配的任务。

# 编排者伪代码（核心是动态任务生成） def orchestrator(user_query): # LLM 生成 JSON 格式任务计划（非自由文本！） plan_json = llm_call( system="你是一个任务规划专家。根据用户查询，生成一个JSON数组，每个元素包含'task'（字符串描述）和'tool'（工具名）。", user=user_query, response_format={"type": "json_object"} # 强制结构化输出 ) # 解析 JSON，分发给执行者 workers_output = [] for task in json.loads(plan_json)["tasks"]: result = worker_llm_call(task["tool"], task["task"]) workers_output.append(result) return aggregate_results(workers_output)

为什么必须用 JSON 强制结构化？Anthropic 的血泪经验：当编排者用自然语言描述任务（如“先看看订单号，再查物流”），执行者 LLM 常因理解偏差执行错误工具。而 JSON 输出可被程序严格校验，缺失字段、非法工具名等错误在分发前即可捕获，避免错误蔓延到执行层。

3.5 评估者-优化者（Evaluator-Optimizer）：让迭代有据可依的闭环机制

此工作流的价值，在于将“LLM 生成 → 人工反馈 → LLM 修改”的模糊过程，转化为可编程、可度量、可终止的机器闭环。评估者（Evaluator）LLM 不是泛泛而谈“这里不好”，而是基于明确定义的评估维度（如“术语一致性”“情感倾向匹配度”“技术细节准确性”）生成结构化反馈。优化者（Optimizer）LLM 则根据该反馈，精准修改对应部分。

# 评估者输出必须是机器可解析的格式 evaluator_output = llm_call( system="你是一个专业翻译评估员。请严格按以下JSON格式输出：{'issues': [{'dimension': '术语一致性', 'location': '第2段第3行', 'suggestion': '将'云端服务'统一为'云服务'...}]", user=f"原文：{source_text}\n译文：{translated_text}" ) # 优化者只修改被标记的部分 for issue in evaluator_output["issues"]: translated_text = apply_suggestion(translated_text, issue)

适用铁律：仅当存在客观、可编码的评估标准时才启用。Anthropic 明确警告：若评估维度模糊（如“整体风格不够优雅”），评估者 LLM 的反馈将充满主观噪音，导致优化者陷入无效循环。他们内部在文学翻译项目中，只启用“术语一致性”“专有名词大小写”“被动语态比例”三个可量化维度，其他交由人工终审。

4. 代理（Agent）：自主性的代价、护栏与不可逾越的沙盒原则

4.1 自主性的双刃剑：为什么“能自己决定下一步”既是核心价值也是最大风险

Anthropic 对代理的定义直击要害：“LLM 能够动态指导自身的处理过程和工具使用的系统”。这意味着代理必须具备三项能力：1）环境感知（能解析工具返回的原始数据，如 API 响应、日志文本、文件内容）；2）状态维护（记住已尝试的方案、已排除的路径、当前卡点）；3）元认知（能判断“我是否真的解决了问题？”，而非仅输出“已完成”）。

但这三种能力共同推高了错误累积风险。一个典型翻车链：代理第一步调用搜索工具，因提示不精准返回了错误文档；第二步基于该错误文档生成代码；第三步运行代码失败；第四步因未设计“回滚机制”，代理开始胡乱修改配置……最终系统崩溃。Anthropic 的数据表明：在未加约束的开放环境中，超过 68% 的代理会在 5 步内因环境反馈误读而偏离目标。因此，“自主性”绝非放任自流，而是在严密护栏内的有限自由。

4.2 代理-计算机接口（ACI）：比提示工程更重要的底层基建

Anthropic 将工具集成（Tool Integration）提升到与模型选型同等重要的地位，并首创“代理-计算机接口（ACI）”概念——它不是 API 调用封装，而是为 LLM 量身定制的人机交互协议。ACI 设计的成败，直接决定代理是“优雅执行”还是“反复碰壁”。

ACI 设计黄金法则（来自 Anthropic SWE-bench 实践）：

• 拒绝“精确计数”开销：要求 LLM 精确指定文件编辑的起始行号（如line_start: 42, line_end: 45）是灾难。模型常因上下文丢失或 token 截断算错行号。改为要求提供唯一可定位的代码锚点（如anchor: "def calculate_total(self):"），再由程序层解析真实行号。
• 拥抱模型熟悉的文本格式：让 LLM 在 JSON 中写代码需转义引号和换行，错误率飙升。改为要求其在 Markdown 代码块中输出：

  ```python def new_function(): return "optimized"

  程序层自动提取代码块内容，零转义负担。

• 工具职责必须原子化、无歧义：避免“edit_file”这种万能工具。拆分为read_file(path)、write_file(path, content)、append_to_file(path, content)。当代理需要“在文件末尾加一行”，它必须明确调用append_to_file，而非让edit_file猜测意图——这极大降低了工具误用概率。

注意：Anthropic 团队透露，在其 SWE-bench 编码代理中，花在 ACI 优化上的时间（约 320 小时）是花在整体提示工程上的 2.3 倍。这印证了一个残酷事实：再精妙的规划提示，也救不了一个让 LLM “猜着用”的工具。

4.3 沙盒与人类监督：代理上线前的不可省略三道关卡

Anthropic 对生产环境代理提出刚性要求：

1. 全链路沙盒（Full-Stack Sandbox）：代理所有工具调用必须在隔离环境中执行。数据库操作走只读副本，文件写入限定在/tmp/agent-sandbox/目录，网络请求经代理网关白名单过滤。任何突破沙盒的行为立即熔断。
2. 人类确认点（Human-in-the-Loop Gates）：在关键决策点设置强制暂停。例如：
   • 当代理首次尝试修改生产数据库 schema 时；
   • 当连续 3 次工具调用返回异常（HTTP 5xx、超时）时；
   • 当代理生成的代码通过静态检查但单元测试失败率 > 30% 时。
     暂停后，系统必须向人类提供可操作摘要（如“检测到 2 处潜在 SQL 注入风险，建议修改第 15 行”），而非仅展示原始日志。
3. 可逆性设计（Reversibility by Default）：每个代理动作必须自带“撤回指令”。例如，create_user(name)工具必须同步生成delete_user_by_name(name)指令；send_email(to, body)必须附带recall_email(id)。Anthropic 强调：“不可逆的操作，就不该交给代理。”

5. 常见误判：开发者最容易踩的五个认知陷阱及破局方法

5.1 误判点：认为“用了 LangChain/LangGraph 就等于在构建 Agent”

为什么错：LangChain 等框架本质是工作流编排胶水，其默认模式仍是预定义节点图。当你用 LangGraph 定义一个固定节点序列（A→B→C→D），即使每个节点调用 LLM，它仍是 Workflow，而非 Agent。真正的 Agent 需要 LLM 在运行时动态决定“下一步是去 E 还是回 B”，而 LangGraph 的图结构在运行时不可变。

怎么看：检验标准只有一个——移除框架，用 20 行 Python while 循环能否复现核心逻辑？如果能，说明你只是用框架做了语法糖包装；如果不能（比如循环中需动态 import 新工具、修改图结构），那才是 Agent 级需求，此时框架反而成了枷锁。

5.2 误判点：把“多轮对话”等同于“代理能力”

为什么错：客服聊天机器人支持 10 轮问答，不等于它是 Agent。若每轮都是独立的“用户问→LLM 答”（无状态、无任务延续、无工具调用），它只是高级版检索问答。真正的代理对话，必须体现跨轮状态继承与目标推进，例如：

• 用户：“查我上周的订单” → 代理调用订单 API，返回订单号 O123；
• 用户：“O123 的物流呢？” → 代理无需用户重复订单号，直接用 O123 调用物流 API。
  这种状态维持，依赖显式 memory 机制（如向量库存储对话摘要）或隐式上下文管理（如将关键 ID 注入后续 prompt），而非框架自带的“历史记录”。

5.3 误判点：追求“全自动化”，忽视人类监督的不可替代性

为什么错：Anthropic 在附录中坦承：“在我们自己的编码代理中，自动化测试能验证功能正确性，但人工审查对确保解决方案符合系统架构、安全规范和长期可维护性仍至关重要。” 试图用 LLM 替代人类做最终决策（如“批准此笔 50 万付款”），是混淆了“执行效率”与“责任归属”。

怎么看：为每个代理设定人类监督强度等级：

• Level 1（低）：仅监控日志，异常时告警；
• Level 2（中）：关键操作前弹出确认框，显示操作摘要与风险提示；
• Level 3（高）：所有操作需人类签名授权，代理仅提供执行建议。
  绝大多数生产场景，Level 2 是性价比最优解。

5.4 误判点：认为“工具越多，代理越强”

为什么错：Anthropic 的合作数据显示，工具数量与代理成功率呈倒 U 型曲线——当工具数从 1 增至 5，成功率上升；但从 5 增至 15，成功率反降 22%。原因在于：工具增多 → 提示中工具描述膨胀 → LLM 注意力分散 → 工具选择准确率下降；工具增多 → 工具间边界模糊 → LLM 混淆调用场景（如该用search_knowledge_base还是query_database）。

怎么看：遵循“一个工具，一个职责，一个名字”原则。定期审计工具集：删除半年未被调用的工具；合并功能重叠的工具（如get_user_profile和fetch_customer_data）；为每个工具添加强制性使用示例（在工具描述末尾写：“正确用法示例：get_user_profile(user_id='U123')”）。

5.5 误判点：在代理中堆砌“高级能力”，忽略基础稳定性

为什么错：开发者常急于加入“自我反思”（self-reflection）、“计划重生成”（plan regeneration）、“多智能体辩论”（multi-agent debate）等炫技功能，却忽视最基础的“工具调用失败重试机制”。Anthropic 观察到，83% 的代理失败源于第一次工具调用超时或返回空结果，而代理未设计重试逻辑，直接崩溃。

怎么看：用“防御性编程”重构代理循环：

for attempt in range(3): # 最多重试 2 次 try: tool_result = call_tool(tool_name, params) if tool_result.is_valid(): # 程序化校验结果有效性 break else: log_warning(f"Attempt {attempt}: Tool {tool_name} returned invalid result") except Exception as e: log_error(f"Attempt {attempt}: Tool call failed with {e}") if attempt == 2: raise AgentExecutionError("Tool failed after max retries")

先让代理“活下来”，再让它“跑得快”。

6. 趋势判断：从“框架崇拜”到“模块主权”的工程范式迁移

6.1 下一个拐点：框架将退居“原型加速器”，生产环境回归原生 API

Anthropic 的指南像一面镜子，照出了当前生态的集体焦虑：我们正用越来越厚的框架抽象层，掩盖对 LLM 底层行为的无知。LangChain 的AgentExecutor、LlamaIndex 的QueryEngine、Bedrock 的 AI Agent Framework，都在用“开箱即用”吸引开发者，却悄悄抬高了调试门槛——当代理出错，你是在 debug 自己的代码，还是 debug 框架的中间件，还是 debug 框架对模型 API 的封装逻辑？三重迷雾叠加，问题定位时间指数级增长。

趋势已明：2024 年底起，头部团队将大规模拆除框架依赖。他们会用原生 Anthropic API（或 OpenAI API）构建核心循环，仅将框架作为 MVP 阶段的“胶水”，一旦进入生产，立刻替换为 200 行以内、完全掌控的 Python 循环。这不是倒退，而是进化——就像 Web 开发从 jQuery 时代回归原生 DOM API，表面看代码量增加，实则获得了对每一个像素、每一次事件的绝对主权。框架不会消失，但它的定位将从“生产基石”降级为“教学演示工具包”。

6.2 关键战场：ACI（代理-计算机接口）将成为新的护城河

当所有团队都能调用同样的大模型，真正的差异化不再来自“谁的提示词更玄学”，而来自“谁的工具接口更让 LLM 如鱼得水”。Anthropic 在附录 2 中透露的细节极具启示性：他们为 SWE-bench 代理优化 ACI 时，最关键的突破不是改提示，而是将文件路径参数从相对路径强制改为绝对路径。这一改动让模型在 99.2% 的场景下正确调用文件工具，错误率从 37% 降至 0.8%。

未来 12 个月，ACI 设计将形成标准化实践：

• 工具描述模板：强制包含purpose（用途）、when_to_use（何时用）、when_not_to_use（何时不用）、common_mistakes（常见错误）四段式；
• 输入验证前置：所有工具调用前，程序层自动校验参数类型、长度、格式（如邮箱正则），非法输入直接拒绝，不传给 LLM；
• 输出 Schema 强约束：工具返回必须是 JSON Schema 定义的结构，程序层自动解析，避免 LLM “自由发挥”输出非结构化文本。
  ACI 将不再是工程师随手写的 API 封装，而是一份需要产品经理、前端、后端、AI 工程师共同签署的《人机协作协议》。

6.3 组织变革：AI 代理团队将分化为“流程考古学家”与“ACI 架构师”

Anthropic 指南反复强调：“从实际工作流程出发”。这意味着，最优秀的 AI 代理工程师，首先必须是顶级的业务流程分析师。他要能坐在客服坐席旁听 3 天电话，画出“用户投诉→坐席查单→升级主管→补偿方案→系统录入”全流程的泳道图，精准识别出哪一步是“人力黑洞”。这类人，Anthropic 称之为“流程考古学家”——他们挖掘的不是文物，而是组织中沉睡的自动化金矿。

而另一类核心角色是“ACI 架构师”。他不关心业务目标，只专注一件事：如何把“查单”这个业务动作，翻译成 LLM 能 100% 理解、100% 可靠执行的工具接口。他要懂 API 设计、懂前端交互、懂数据库事务，更要懂 LLM 的 token 限制、上下文窗口、输出偏好。这两类人必须组成最小作战单元，缺一不可。未来招聘启事上，“熟悉 LangChain”将不再是硬性要求，但“能独立完成端到端业务流程拆解”和“有 ACI 设计落地经验”将成为黄金标准。

从那以后我每次启动新代理项目，都强制走一遍“三问流程”：

1. 问业务：“这个代理要替代哪个具体岗位的哪项具体操作？请给我一份该操作的标准 SOP 文档。”
2. 问工具：“为支撑这项操作，我们需要哪些外部系统访问权限？这些系统的 API 是否支持幂等调用？失败时能否提供结构化错误码？”
3. 问护栏：“如果这个代理在生产环境失控，最坏情况会损失什么？我们的沙盒、熔断、回滚机制能否在 5 秒内阻止损失？”
   漏掉任何一问，项目就埋下雷。希望帮到你。

本文还有配套的精品资源，点击获取