1. 这道题不是考“Agent”名词而是考你有没有真正跑过一个带规划的智能体“Agent 怎么做规划”——当面试官把这句话抛出来坐在对面的候选人往往下意识开始背诵ReAct、Plan-and-Execute、Tree of Thoughts、LLM-as-a-Judge……语速飞快术语连珠PPT里甚至画出了带箭头的流程图。但十有八九话音刚落面试官就轻轻敲了敲桌面“你刚才说的‘Plan-and-Execute’在真实任务中如果第一步生成的 plan 要求调用一个根本不存在的 API后续怎么拦是让 LLM 自己发现错误重试还是你在代码里加了 fallback 逻辑这个 fallback 的触发条件你是用字符串匹配‘not found’还是解析 HTTP 状态码又或者监听了底层 SDK 抛出的具体异常类型”这时候空气就静了。我参与过三年多的 AI 工程师校招与社招面试也带过多个从零搭建 Agent 系统的内部项目。这道题之所以能筛掉八成以上的人并非因为它有多艰深而在于它是一面照妖镜照出你是真正在终端里敲过python main.py并盯着日志一行行 debug 过还是只在 Colab notebook 里跑通过官方示例的agent.invoke({input: 查一下今天北京天气})。关键词不是“Agent”也不是“规划”而是“怎么做”——三个字直指工程落地中最硬的那块骨头规划不是一次性的 prompt 工程而是一套可中断、可回溯、可降级、可监控的状态机闭环。很多人误以为“加个 planner 模块”就是做了规划。实则不然。真正的规划能力体现在系统面对“计划失败”时的肌肉记忆当工具调用超时、当 LLM 返回格式错乱、当用户中途插入新指令、当外部服务返回意料之外的 schema 变更……你的系统是直接崩掉报错还是安静地切到备用方案同时记下一笔可观测的 trace后者才是工业级 Agent 的分水岭。这背后牵扯的远不止模型调用技巧。它要求你对 LLM 的 token 生成机制有手感比如知道为什么{action: search, query: 2024年Q3财报}有时会突然变成{action: search, query: 2024年Q3财报, source: internal}多出一个字段对工具封装的抽象层级有判断是把整个 Requests Session 封进 Tool还是只暴露get_weather(city: str)这样语义清晰的函数对状态持久化的成本有预估用 Redis 存 plan tree 还是纯内存plan 执行到第三步崩溃重启后如何续上。这些细节没有一次真实的、带压测的、被业务方催着上线的项目锤炼光靠读论文和抄 demo永远只能停留在“知道有这么回事”的层面。所以这篇文章不讲概念定义不列论文索引也不堆砌架构图。我们直接钻进一个最典型的规划失败现场一个电商客服 Agent在处理“帮我找一下上周退货但还没收到退款的订单”这个请求时规划链路是如何一步步断裂又是如何被一层层补救回来的。所有代码、配置、日志片段、监控埋点都来自某跨平台客服系统的真实迭代记录——只是我把公司名、接口地址、内部 SDK 名称全部替换为通用代称确保内容安全且可复现。你不需要是算法专家但得是个靠谱的工程师。接下来的内容每一行都对应着我踩过的坑、改过的 config、重写的 retry 逻辑以及最终上线后监控面板上那条平稳下降的 error rate 曲线。2. 规划的本质不是“想清楚再干”而是“边干边想、错了就换”很多候选人一上来就谈“分而治之”“任务分解”听起来很美。但如果你真去翻看主流 Agent 框架LangChain、LlamaIndex、Semantic Kernel的 issue 区高频问题永远是“Plan step 2 调用工具失败后整个 chain 就卡死了怎么让它自动重试或跳过”——这说明绝大多数人对“规划”的理解还停留在静态的、线性的、理想化的脑内沙盘推演阶段。真实世界的规划必须是动态的、带反馈的、容忍噪声的。它的核心循环我把它拆解成四个不可省略的环节缺一不可2.1 环节一Plan 生成 ≠ 生成 JSON而是生成“可验证的执行契约”很多人以为只要 prompt 里写清楚 “请输出 JSON 格式包含 action 和 args”LLM 就会乖乖听话。错。LLM 是概率模型不是确定性程序。它可能在 95% 的情况下输出合法 JSON但在关键的 5% 场景下比如输入里混入了用户随手粘贴的乱码、或者上下文 token 快爆了它就会“自由发挥”输出类似这样的东西好的我来帮你查首先需要获取你的订单列表然后筛选出上周退货的订单最后检查退款状态。 { action: list_orders, args: {status: returned, time_range: last_week} }注意开头多了两行自然语言描述。这对 parser 来说就是致命伤。很多开源 demo 用json.loads(response)硬解析结果直接JSONDecodeError崩溃。我们的解法是绝不信任原始输出必须加一层“契约校验层”。不是简单地 try-except而是设计一个轻量级的 Schema Validatorfrom pydantic import BaseModel, Field from typing import Optional, Dict, Any class PlanStep(BaseModel): action: str Field(..., description工具名称必须是已注册的合法工具) args: Dict[str, Any] Field(default_factorydict, description工具参数) reason: str Field(..., description此步骤的简明理由用于审计) class PlanOutput(BaseModel): steps: list[PlanStep] Field(..., description有序的执行步骤列表) final_answer: Optional[str] Field(None, description若无需执行直接回答) # 使用示例用 Pydantic 的 parse_raw 配合 strictTrue try: plan PlanOutput.parse_raw(llm_response, strictTrue) except Exception as e: # 记录错误日志触发 fallback 流程 logger.warning(fPlan validation failed: {e}, raw response: {llm_response[:200]}) return handle_plan_parsing_failure(llm_response)提示Pydantic 的strictTrue是关键。它强制要求输入必须是严格符合 JSON Schema 的字符串不会尝试“宽容解析”。这比手写正则或json.loads()安全得多。而且PlanStep.action字段的Field(..., description...)不仅是文档更是后续工具路由的依据——我们用它做白名单校验任何不在registered_tools.keys()里的 action直接拒绝执行避免 LLM “幻觉”出不存在的工具。这个环节的价值是把“LLM 输出”这个黑盒转化成一个带有明确结构、可编程校验、可审计追溯的“执行契约”。它不解决 LLM 会不会出错但它确保一旦出错系统能第一时间感知并进入可控的降级路径。2.2 环节二Plan 执行 ≠ 调用函数而是启动一个“带超时与熔断的事务”生成了一个合法的 PlanStep下一步是执行。很多人以为tool_map[step.action](**step.args)就完事了。但现实是list_orders这个工具背后可能是一个调用第三方支付网关的 HTTP 请求。它可能因为网络抖动超时可能因为对方限流返回 429可能因为 schema 升级导致order_id字段突然变成了orderId。如果代码里没做任何防护一次超时就会让整个 Agent 卡死几十秒用户体验直接归零。我们的标准实践是每个工具调用都必须包裹在一个统一的execute_tool_with_safeguards函数里。它集成了三重保险硬超时Hard Timeout使用asyncio.wait_for或requests.Timeout设定一个绝对上限如 8 秒。超过即刻中断不等、不拖、不重试。软重试Soft Retry对明确的、可恢复的错误如 429 Too Many Requests, 503 Service Unavailable进行指数退避重试最多 2 次间隔 0.5s/1s。熔断器Circuit Breaker基于滑动窗口统计最近 10 次调用的成功率。如果成功率低于 60%自动开启熔断后续 60 秒内所有对该工具的调用直接返回预设的 fallback 响应如{orders: []}不再发起真实请求。import asyncio from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type from circuitbreaker import circuit circuit(failure_threshold3, recovery_timeout60) retry( stopstop_after_attempt(2), waitwait_exponential(multiplier0.5, min0.5, max1), retryretry_if_exception_type((requests.exceptions.Timeout, requests.exceptions.ConnectionError)) ) async def execute_tool_with_safeguards(tool_name: str, tool_func, **kwargs): try: # 硬超时8秒内必须返回 result await asyncio.wait_for(tool_func(**kwargs), timeout8.0) return {status: success, data: result} except asyncio.TimeoutError: logger.error(fTool {tool_name} timed out after 8s) raise except Exception as e: logger.exception(fTool {tool_name} execution failed: {e}) raise # 在 Agent 主循环中调用 try: tool_result await execute_tool_with_safeguards(step.action, tool_map[step.action], **step.args) except Exception as e: # 进入 Plan 执行失败处理分支 return await handle_tool_execution_failure(step, e)注意circuit装饰器和tenacity.retry装饰器的组合是经过生产环境验证的黄金搭档。前者防雪崩后者保弹性。不要试图用一个装饰器包打天下。另外asyncio.wait_for的 timeout 值必须小于tenacity的总重试耗时否则重试逻辑会被外层超时直接掐断失去意义。这个环节的价值是把“一次函数调用”升级为一个具备韧性Resilience的微服务调用。它让规划不再是纸面上的完美路线图而是一条在真实网络世界里能自己绕开坑洼、识别红灯、并知道何时该停车的智能路径。2.3 环节三Plan 监控 ≠ 打印日志而是构建“可关联的 Trace 链”当 Plan 执行失败你第一反应是什么是翻stdout里那几行模糊的ERROR: Tool list_orders failed还是能立刻在 Grafana 上定位到这是第 17234 号用户会话在执行 Plan 的第 2 步时因payment_gateway服务连续三次 503触发了熔断进而导致整个 Plan 中断后者才是规划监控的正确姿势。我们的做法是为每一次 Agent 调用生成一个全局唯一的trace_id并贯穿 Plan 生成、每一步执行、结果聚合、最终响应的全过程。所有日志、指标、链路追踪我们用 OpenTelemetry都带上这个trace_id。# 在 Agent 入口处生成 from opentelemetry import trace from opentelemetry.trace import SpanKind tracer trace.get_tracer(__name__) async def run_agent(input_text: str, session_id: str): trace_id ftrace-{int(time.time() * 1000000)}-{session_id[-6:]} # 简化版实际用 UUID with tracer.start_as_current_span(agent.run, kindSpanKind.SERVER, attributes{session.id: session_id, trace.id: trace_id}): logger.info(f[{trace_id}] Agent started for session {session_id}) # Plan Generation with tracer.start_as_current_span(plan.generate): plan await generate_plan(input_text, trace_id) # Plan Execution with tracer.start_as_current_span(plan.execute): for i, step in enumerate(plan.steps): with tracer.start_as_current_span(fstep.{i1}.execute, attributes{step.action: step.action}): result await execute_tool_with_safeguards(step.action, tool_map[step.action], **step.args, trace_idtrace_id)这样当step.2.execute的 span 显示status_code503且error.typeHTTPError时运维同学可以直接点击这个 span下钻看到它关联的所有日志包括上游plan.generate的完整 prompt 和 output以及下游agent.run的整体耗时。故障定位时间从小时级缩短到分钟级。提示trace_id不仅是给运维看的。它也是你做 A/B 测试的基础。比如你想对比两种 PlannerReAct vs. ToT在“退货退款查询”这类任务上的成功率只需在plan.generate的 span 里加一个planner.typeattribute然后在 Prometheus 里写一个简单的rate(http_server_duration_seconds_count{planner_typereact, status_code500}[1h])数据就出来了。没有 trace_id一切分析都是空中楼阁。这个环节的价值是把“规划”从一个单次、孤立的推理过程变成一个可观测、可度量、可优化的工程产品。它让你能回答那个最灵魂的问题“我们的规划能力到底提升了多少”2.4 环节四Plan 修复 ≠ 重新生成而是执行“最小代价的局部重规划”这是区分“玩具 Agent”和“生产 Agent”的最后一道门槛。当 Plan 第 3 步失败常见做法是把前两步的成功结果 失败信息一股脑塞回 LLM让它“重新想一个完整的 plan”。这看似合理实则低效且危险。原因有三上下文爆炸前两步的输出比如一个 50 行的订单列表 错误信息 新的 prompt很容易突破 LLM 的 context window导致关键信息被截断。信息污染LLM 可能被前两步的“成功”细节干扰忽略了当前的核心障碍比如“支付网关挂了”它却去优化“订单筛选逻辑”。状态丢失前两步产生的中间状态如已缓存的订单 ID 列表如果没被妥善管理重规划时就得重新拉取浪费资源。我们的方案是实施“局部重规划Local Replanning”。当某一步骤失败我们只将以下三样东西喂给 LLM失败步骤的原始 PlanStep{action: check_refund_status, args: {order_id: ORD-7890}}失败的具体原因HTTPError: 503 from payment_gateway service一个极其精简的指令请仅修改此步骤的 action 和 args使其能绕过当前故障。不要修改其他步骤不要添加新步骤。async def local_replan(failed_step: PlanStep, error_message: str) - PlanStep: # 构造极简 prompt prompt f你是一个精准的工具调度器。当前有一个执行步骤失败了 步骤{failed_step.json()} 错误{error_message} 请仅修改此步骤的 action 和 args 字段使其能绕过当前故障例如换一个更稳定的工具、调整参数、增加重试标识。 严格遵守不修改其他字段不添加新步骤不解释原因只输出修正后的 JSON。 # 调用 LLM注意这里用的是更小、更快的模型如 Phi-3-mini而非主推理模型 corrected_json await llm_mini.invoke(prompt) return PlanStep.parse_raw(corrected_json)在这个例子中LLM 可能会把check_refund_status改成check_refund_status_fallback一个内部降级工具查本地缓存而非实时网关或者把args里的order_id换成一个更宽泛的user_id参数以触发另一个可用的查询路径。注意我们特意用了更小、更快的模型来做局部重规划。因为任务极其简单就是字段映射没必要消耗昂贵的大模型 token。这既是成本控制也是性能保障。主模型只负责高价值的全局规划低价值的“打补丁”工作交给小模型。这个环节的价值是赋予了规划系统一种“外科手术式”的纠错能力。它不追求完美但追求高效不追求一次成功但追求最小扰动下的快速恢复。这才是一个成熟 Agent 应有的“肌肉记忆”。3. 那些被 80% 候选人忽略的“脏活累活”恰恰是规划落地的命脉面试官问“Agent 怎么做规划”其实在问“你有没有亲手干过那些没人愿意写文档、但系统离了它就转不动的脏活累活” 这些活儿不炫技不性感但决定了你的 Agent 是能跑通 demo还是能扛住双十一流量。3.1 脏活一Plan 的序列化与反序列化不是json.dumps()就完事Plan 对象PlanOutput要能在不同进程、不同机器间传递就必须序列化。很多 demo 直接json.dumps(plan.dict())然后json.loads()。这在简单场景下没问题但一旦 Plan 里包含了datetime、Enum、自定义BaseModel或者工具返回的numpy.ndarray虽然不推荐但真实存在就会报错。我们的标准方案是用pydantic.BaseModel.json()json.loads()的组合并为所有可能的非标类型注册自定义 encoder。from datetime import datetime from enum import Enum class ToolStatus(str, Enum): SUCCESS success FAILED failed class ToolResult(BaseModel): status: ToolStatus data: dict timestamp: datetime # 注册自定义 encoder def custom_json_serializer(obj): if isinstance(obj, datetime): return obj.isoformat() elif isinstance(obj, Enum): return obj.value elif hasattr(obj, dict) and callable(getattr(obj, dict)): return obj.dict() else: raise TypeError(fObject of type {type(obj)} is not JSON serializable) # 序列化 plan_json plan.json(encodercustom_json_serializer) # 反序列化注意pydantic 会自动处理 datetime 和 Enum plan_restored PlanOutput.parse_raw(plan_json)提示pydantic.BaseModel.json()是比json.dumps(model.dict())更安全的选择。它内置了对datetime、UUID、Enum的支持且parse_raw()能保证类型安全。别偷懒这是基础中的基础。3.2 脏活二Plan 的版本兼容性不是“升级就完事”而是“灰度双写迁移”你的 Agent 系统上线了用户量涨了业务方提了新需求你要升级 Planner 模型让它支持更复杂的“多条件交叉筛选”。新模型生成的 PlanPlanStep里多了一个filter_strategy: str字段。老版本的 Executor 代码不认识这个字段PlanStep.parse_raw()就会直接失败。我们的发布流程是双写Dual Write新 Planner 同时生成新旧两种格式的 Plan并存入 Redis。Key 分别是plan_v1:{trace_id}和plan_v2:{trace_id}。灰度CanaryExecutor 代码里加一个开关PLAN_VERSION os.getenv(PLAN_VERSION, v1)。先对 1% 的流量开启v2观察错误率。迁移Migration当v2稳定运行一周错误率低于v1再将开关全局切到v2并清理v1的存储。# Executor 中的兼容逻辑 def get_plan(trace_id: str) - PlanOutput: version os.getenv(PLAN_VERSION, v1) if version v2: plan_data redis_client.get(fplan_v2:{trace_id}) else: plan_data redis_client.get(fplan_v1:{trace_id}) # 如果 v2 不存在降级到 v1 if not plan_data and version v2: plan_data redis_client.get(fplan_v1:{trace_id}) logger.warning(f[{trace_id}] Fallback to v1 plan) return PlanOutput.parse_raw(plan_data)提示永远假设你的上下游是不可信的。Plan 的 schema 就是你的 API 协议。协议升级必须像微服务 API 升级一样严肃对待。没有双写和灰度就是裸奔。3.3 脏活三Plan 的生命周期管理不是“用完就扔”而是“存档过期清理”一个用户的一次会话可能产生 5 个 Plan初始规划 4 次局部重规划。这些 Plan 数据是宝贵的调试资产、审计依据、甚至未来训练数据。但它们不能无限堆积。我们的策略是分级存储 TTL 定时清理。热数据 1 小时存在 RedisTTL 设为 2 小时供实时监控和快速 debug。温数据1 小时 - 7 天异步写入对象存储如 S3按date2024-06-15/session_idabc123/trace_idtrace-xxx.json的路径组织便于按日期和会话检索。冷数据 7 天归档到 Glacier成本极低仅用于法律合规审计。清理脚本每天凌晨执行# 清理 Redis 中过期的 Plan redis-cli --scan --pattern plan_* | xargs -I {} redis-cli expire {} 7200 # 清理 S3 中 7 天前的文件使用 AWS CLI aws s3 ls s3://my-bucket/plans/ --recursive | awk $1 $(date -d 7 days ago %Y-%m-%d) {print $4} | xargs -I {} aws s3 rm s3://my-bucket/{}提示Plan 存档不是可选项是必选项。某次线上事故就是因为一个罕见的list_orders工具 bug只在特定用户标签组合下触发。没有存档的 Plan我们花了三天才复现出来。有了存档5 分钟就定位了。3.4 脏活四Plan 的人工审核通道不是“全自动”而是“人在环上”再完美的自动化也有失灵的时候。比如LLM 局部重规划后把check_refund_status改成了refund_money_now——一个本不该由客服 Agent 触发的、具有强副作用的财务操作。我们的系统里永远保留一条“人工审核”逃生通道。当 Plan 中出现任何被标记为high_risk: true的PlanStep比如 action 名字里含refund,cancel,delete系统会自动暂停将trace_id和当前 Plan 推送到内部审批群并等待管理员在 Web 控制台点击“批准”或“拒绝”。# 在 Plan 执行前的校验环节 for step in plan.steps: if step.action in HIGH_RISK_ACTIONS: # [refund_money_now, cancel_subscription] await send_approval_request(trace_id, step) approval await wait_for_admin_approval(trace_id, timeout300) # 5分钟超时 if not approval: raise PlanExecutionBlockedError(fHigh-risk step {step.action} requires manual approval)提示这条通道的存在不是对自动化的否定而是对业务底线的守护。它让工程师可以放心地迭代更激进的 Planner 策略因为知道最坏情况有兜底。这是一种成熟工程文化的体现。4. 从“能跑”到“跑好”规划能力的量化评估与持续优化面试官问“怎么做规划”终极答案应该是你能拿出一份清晰的、可量化的、持续更新的“规划健康度报告”。这不是 PPT 里的漂亮图表而是你每天打开监控面板一眼就能看到的数字。我们定义了四个核心指标它们共同构成了规划能力的“仪表盘”指标名称计算公式健康阈值业务含义如何采集Plan 生成成功率 (PGS)1 - (生成失败次数 / 总请求次数)≥ 99.5%LLM 是否稳定输出合法 Planplan.generatespan 的status_codePlan 执行成功率 (PES)1 - (执行失败次数 / 总执行步骤数)≥ 98.0%工具链是否健壮熔断是否有效step.X.executespan 的status_code平均规划深度 (APD)Σ(Plan.steps.length) / 总请求次数2.5 ± 0.5规划是否足够“聪明”能否减少步骤plan.steps.length字段局部重规划率 (LRR)局部重规划次数 / 总失败步骤数≤ 30%系统是否倾向于“打补丁”而非“推倒重来”日志中local_replan的出现频次这张表是我们每周站会的起点。如果某周PES从 98.2% 掉到了 96.5%我们就立刻下钻是某个工具比如payment_gateway的503错误突增→ 查看该工具的熔断器状态和上游监控。是LRR同步飙升→ 检查局部重规划的 prompt 是否被 LLM “误解”导致它总在生成无效的 fallback。是APD异常升高→ 可能是 Planner 模型在复杂 query 下“过度思考”需要加更严格的 step 数限制。持续优化就藏在这些数字的微小波动里。我们做过一个实验把PlanStep.reason字段的长度限制从 50 字放宽到 100 字。结果PGS提升了 0.3%因为 LLM 有了更多空间去“解释自己为什么这么想”反而降低了胡编乱造的概率。这种优化没有高大上的算法只有对数据的敬畏和对细节的抠门。最后分享一个真实案例我们曾发现LRR在每天上午 10 点准时飙升。排查后发现是内部一个定时任务在 10 点同步上游 CRM 数据导致list_customers工具短暂变慢触发了熔断进而引发大量局部重规划。解决方案不是改 Planner而是把这个定时任务错峰到凌晨 3 点。一个运维层面的调整让规划系统的稳定性曲线一夜之间变得平滑。所以回到那道面试题。“Agent 怎么做规划”——我的答案是用工程化的方法把一次充满不确定性的 LLM 推理封装成一个具备可观测性、可韧性、可度量、可演进的确定性服务。它不神秘它很琐碎它不依赖某个天才的灵光一现而依赖于每一天、每一行代码、每一个监控告警、每一次复盘会议的积累。当你能把这套逻辑结合你自己的项目讲出具体的trace_id、具体的error_code、具体的fallback代码片段时你就已经超越了那 80% 的人。剩下的 20%拼的就是谁的“脏活累活”干得更扎实谁的“仪表盘”看得更清楚。我在实际使用中发现最有效的学习方式不是去读最新的 arXiv 论文而是打开你正在用的 Agent 框架的源码找到它的plan.py或executor.py文件然后对着生产环境的错误日志一行一行地跟进去。看看那个JSONDecodeError到底是从哪一行json.loads()抛出来的看看那个TimeoutError是不是因为wait_for的 timeout 值设得太小。这种带着具体问题的源码阅读比任何教程都管用。毕竟规划的真谛从来不在云端而在你键盘敲下的每一行try...except里。