智能体方案先判断值不值得做规划新功能时Agent 常被当成默认答案。其实先要判断流程中是否真的有需要理解歧义、跨工具规划或处理非结构化内容的环节。若输入字段明确、规则稳定、失败后果又很重普通表单校验和工作流通常更合适。1. 简单的规则匹配就能解决的问题没必要引入 Agent许多所谓的多模态 Agent 场景仔细拆解逻辑就会发现核心诉求不过是把用户上传的发票图片解析出金额和税号再调用财务接口落库。如果一个流程只是在 OCR 结果中提取固定字段再调用已定义的接口先用确定性流程实现再评估是否存在模型能带来的增量价值[用户上传发票] │ ▼ [大模型感知图片] ➔ [模型推理是否调用 OCR 工具] ➔ [模型生成 Tool Call JSON] ➔ [服务端执行工具] ➔ [模型接收结果再输出 JSON]这不仅把原本一次 API 解决的问题变成了 3 次 HTTP 往返延迟从 200ms 剧增到 4 秒以上每次调用的 Token 成本也翻了数十倍。在设计系统前必须先回答一个问题这个业务节点真的存在“需要模型自主规划”的不确定性吗如果答案否硬套 Agent 就是给系统找麻烦。2. 多模态交互引发的图像 Token 膨胀与时延飙升在多模态 Agent 实验中图片和视频帧输入的开销远超纯文本。目前主流的大模型在处理一张 1080P 分辨率的图片时根据 Tile 机制切割切片通常会转换成 1000 到 1500 个 Image Tokens。在连续对话或者多轮 Agent 思考循环中如果每次 Tool Calling 交互都把之前历史中的多张高分辨率图片重复传给模型Context Window 会瞬间膨胀。如果不做图像尺寸下采样Downsampling和 ROI感兴趣区域裁剪连续 5 轮 Agent 思考就会吐掉几万 Tokens接口响应延迟直接逼近 10 秒大关。3. Tool Calling 无限死循环与 Token 熔断防御LLM 的非确定性决定了它有可能出现盲目重复执行某个工具的极端情况。例如在调用查询 API 返回空列表时模型可能不会总结并退出而是一直尝试调用同一个 API直到上下文长度溢出或超时。在生产环境里决不能把循环终止的希望寄托在 LLM 的自我觉察上。必须在 Agent 框架的底层外壳设置确定性的“闸门机制”。以下是带有状态跟踪和重复调用熔断机制的 Agent 执行引擎代码import json import hashlib from typing import List, Dict, Any, Callable class AgentExecutionError(Exception): pass class SafeAgentExecutor: def __init__( self, llm_client, tools_map: Dict[str, Callable], max_turns: int 5, max_tool_repeats: int 2 ): self.llm_client llm_client self.tools_map tools_map self.max_turns max_turns self.max_tool_repeats max_tool_repeats def _compute_action_hash(self, tool_name: str, tool_args: Dict[str, Any]) - str: # 将工具名与参数做 Hash精确识别重复动作 raw_str f{tool_name}:{json.dumps(tool_args, sort_keysTrue)} return hashlib.md5(raw_str.encode(utf-8)).hexdigest() def run(self, user_query: str) - Dict[str, Any]: messages [{role: user, content: user_query}] action_history [] action_counts: Dict[str, int] {} for turn in range(1, self.max_turns 1): # 1. 强行截断过长上下文防止 Token 消耗失控 response self.llm_client.chat(messagesmessages, toolsself._get_tool_schemas()) # 如果模型给出了最终文本回答直接返回 if response.get(type) text: return {status: success, turns: turn, output: response[content]} # 2. 模型发起 Tool Calling if response.get(type) tool_call: tool_name response[tool_name] tool_args response.get(tool_args, {}) action_hash self._compute_action_hash(tool_name, tool_args) action_counts[action_hash] action_counts.get(action_hash, 0) 1 # 3. 硬性断路器相同工具与相同参数连续重复执行超过阈值直接熔断 if action_counts[action_hash] self.max_tool_repeats: raise AgentExecutionError( f检测到 Agent 陷入死循环工具 {tool_name} 使用参数 {tool_args} 已重复执行 {action_counts[action_hash]} 次。 ) # 4. 安全执行本地工具 if tool_name not in self.tools_map: raise AgentExecutionError(f模型试图调用不存在的工具: {tool_name}) try: tool_result self.tools_map[tool_name](**tool_args) except Exception as e: tool_result fTool execution failed with error: {str(e)} # 5. 将工具返回结果回填至上下文 messages.append({role: assistant, tool_calls: [response[tool_call_id]]}) messages.append({role: tool, content: str(tool_result), tool_call_id: response[tool_call_id]}) action_history.append(action_hash) # 超过最大思考轮次走工程降级 return {status: degraded, turns: self.max_turns, output: 系统未能完成复杂推演已为您转交人工处理。} def _get_tool_schemas(self) - List[Dict[str, Any]]: # 返回标准化 Tool Schema return []代码逻辑中通过_compute_action_hash记录每一轮调用的特征一旦发现模型在重复执行完全相同的工具和参数立刻中断执行。这种断路器设计是把 Agent 推向生产环境的基本安全线。4. 评估 AI Agent 落地价值的几条定量指标在决定是否为一个业务引入 Agent 架构时可以参考以下这套简单评估公式$$ROI_Score \frac{\text{柔性推演带来的收益} \times \text{业务容错度}}{\text{API 额外延迟} \times \text{Token 成本倍数}}$$对实时性和准确性要求很高的动作应将模型放在建议、预填或人工复核之前而非放在最终执行点。适合试点的场景往往允许失败、结果可复核并且人工处理确实耗时。5. 务实的工程架构演进路线放弃对 Agent 全能性的妄想采取“小步快跑、确定性优先”的策略优先使用代码流控制状态机用 LangGraph 或自研状态机确定大致流程只在具体的节点分支放开给 LLM 决策。多模态数据提前抽离降维图片上传后立即在前端或边缘网关提取文本 OCR 与结构化标签避免全量大图在多轮 Agent 思考中反复传输。设置严格的死循环熔断与降级策略限制单次任务的最大思考轮次与重复工具调用上限一旦超时立刻切回常规工单系统。架构选择要写清楚假设、预算与退出条件。这样即使试点不成立也能及时收回复杂度。