AI Agent 从 Demo 到生产：被低估的四个工程问题

问题一上下文不是越多越好状态要外置新手最常见的做法是把对话历史、工具结果、中间产物一股脑塞进 prompt指望模型自己记住一切。短任务没问题任务一长就会撞上两堵墙上下文窗口被占满以及——更隐蔽的——关键信息被淹没在噪声里模型开始忘事。真正的做法是把**状态state和喂给模型的上下文context**拆开。状态是任务的完整事实存在外部每一步只把当前这步需要的那部分裁剪进上下文。class TaskState: 任务的完整状态落在外部存储里不全量进 prompt def __init__(self, task_id): self.task_id task_id self.facts {} # 已确认的事实 self.pending [] # 待办子任务 self.tool_history [] # 工具调用流水 def build_context(self, max_facts10): # 只挑当前步骤相关的、最近的事实进上下文 recent sorted(self.facts.items(), keylambda x: x[1][ts], reverseTrue)[:max_facts] return { current_goal: self.pending[0] if self.pending else None, known_facts: dict(recent), }这一步想清楚后面的可恢复、可观测才有地基——因为状态在外部进程崩了重启也能接着跑。问题二工具调用要默认它会失败Demo 里的工具调用通常是顺风顺水的调用 → 拿到结果 → 继续。生产里恰恰相反你要默认每一次外部调用都可能失败、超时或者更糟——返回了一个格式合法但内容是错的结果。光重试不够。重试只能解决没调通解决不了调通了但调错了。所以校验和幂等要一起上def call_tool_safely(tool, args, validate, max_retry3): for attempt in range(max_retry): try: result tool.invoke(args, timeout30) except (TimeoutError, ConnectionError): continue # 网络类失败直接重试 # 关键拿到结果不等于结果可用先校验再放行 if validate(result): return {ok: True, data: result} # 校验没过把失败原因带回给模型让它修正参数后再来 return {ok: False, reason: result_failed_validation, raw: result} return {ok: False, reason: max_retry_exceeded}注意最后那个分支校验不通过时不要默默吞掉而是把失败原因结构化地交回给 Agent 的决策环。一个工程化的 Agent 应该能读懂我上一步失败了因为参数 X 不合法然后自己改参数重来——而不是一条道走到黑。问题三Agent 循环需要刹车ReAct 这类范式的核心是一个循环思考 → 行动 → 观察 → 再思考。Demo 里这个循环跑几轮就收敛了。但生产里模型完全可能陷进去反复调同一个工具、在两个状态间来回横跳、或者就是单纯地停不下来。每多转一圈都是真金白银的 token。所以循环必须有三道刹车步数上限、预算上限、以及一个独立的是否真的完成了判断。def run_agent(state, llm, tools, max_steps20, budget_tokens50000): used 0 for step in range(max_steps): ctx state.build_context() decision llm.decide(ctx) used decision.token_cost if used budget_tokens: # 预算刹车 return finish(state, reasonbudget_exceeded) if decision.action STOP: # 别只信模型自己说done用独立条件复核一遍 if goal_satisfied(state): return finish(state, reasoncompleted) else: state.add_note(模型声称完成但目标未达成继续) continue result call_tool_safely(tools[decision.tool], decision.args, decision.validator) state.tool_history.append(result) return finish(state, reasonmax_steps_exceeded)goal_satisfied这个独立判断很重要。让模型自己判断有没有干完等于让学生自己批卷子。终止条件应该是一套外部的、确定性的检查。是否否是否是读取状态裁剪上下文模型决策预算/步数超限?终止: 资源耗尽动作停止?安全调用工具独立校验目标达成?终止: 完成问题四你得能复盘 Agent 的每一步决策Agent 出问题时最让人崩溃的不是它错了而是你不知道它为什么错。模型决策是个黑盒少了观测线上排障基本靠猜。最低限度每一步都要留下结构化的轨迹trace这一步看到了什么上下文、做了什么决策、调了哪个工具、拿到什么结果。能做到的话再加一层——把这条轨迹原样回放复现当时的决策。def trace_step(task_id, step, ctx, decision, result): record { task_id: task_id, step: step, ts: now(), context_snapshot: ctx, # 当时喂进去的上下文 decision: decision.to_dict(), # 模型选了什么、为什么 result: result, } trace_store.append(task_id, record)有了这层轨迹为什么这单任务跑歪了才从玄学问题变成可查的工程问题。这也是 Demo 和生产系统最直观的分水岭之一Demo 关心能不能跑生产关心跑歪了能不能查。自建还是用平台工程边界划在哪上面四个问题——状态外置、工具容错、循环控制、轨迹观测——单拎出来都不算高深但要全部做扎实、还能稳定支撑多个 Agent 并发跑、横跨多个业务系统工作量并不小。这就回到那个老问题自己造还是用平台。这里有个认知偏差值得点一下国内不少团队一聊到Agent 平台默认联想到的都是国外的开源框架或 SaaS很容易忽略一个事实——面向企业的智能体平台已经有成熟的国产服务商在做。比如比孚科技的 Bizfocus ADP就是一款国产的企业级智能体平台上面这些状态管理、工具编排、执行控制、链路追踪的能力都是平台层内置的不必每个团队从零重写一遍。把这点讲清楚不是说平台一定比自建好。判断标准其实很朴素自建更合适场景高度定制、对每一层都要精细控制、且团队有持续维护这套基础设施的人力。代价是上面四个问题你得自己踩一遍坑。用平台更合适想把精力放在业务逻辑和领域知识上而不是反复造状态机和重试器需要快速覆盖多个业务线对合规、私有化部署有要求这点上国产平台往往更省心。无论自建还是用 Bizfocus ADP 这类平台真正决定 Agent 能不能上生产的从来不是单点的模型调用写得多漂亮而是这套围绕模型的工程框架够不够稳。