当前位置：首页 > news >正文

一次Agent项目复盘，问题最后出在流程而不是模型

news 2026/7/21 5:50:48

这篇我按“先跑起来、再讲取舍”的方式写《一次Agent项目复盘，问题最后出在流程而不是模型》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

之前有个读者问我：“为什么我在 Jupyter Notebook 里跑通的 Agent，一放进生产环境就炸？”

他的 Agent 逻辑很简单：读取用户意图 -> 调用搜索工具 -> 生成报告。Demo 阶段，大模型偶尔会“幻觉”，比如搜不到东西时瞎编一个链接，但用户通常不会深究，或者手动纠正一下也就过了。然而一旦进入生产，情况完全不同。有一次，Agent 因为搜索接口超时，没有触发正确的错误处理，而是陷入了一场死循环重试，直接把服务器的 CPU 打满了，连带着把正常的数据库连接池也给挤爆了。

这就是我今天要复盘的核心：从 Demo 到生产，Agent 的瓶颈从来不是模型的智商，而是工程化的底线——权限控制、全链路日志和可观测性。

很多开发者沉迷于 LangChain 或 LangGraph 的高级编排功能，试图用复杂的图结构来解决所有问题。但在实际项目中，我砍掉了三个“想当然”的功能：自动重试无限次、不限制的工具访问权限、以及缺乏状态快照的记忆系统。

以下是我对 Agent 核心原理（工具调用、记忆、任务规划）在工程化视角下的重新审视。

Agent 的本质：不是推理机，是执行器

我们常把 Agent 想象成一个拥有大脑的 AI 角色，但实际上，在生产环境中，它更像是一个需要严格约束的“初级实习生”。它拥有极强的学习能力（通过 Prompt），但缺乏常识判断，且容易受到诱导。

因此，Agent 的设计初衷不应是“全自动完成复杂任务”，而应是“在受限范围内可靠地执行特定流程”。

在我的最近一个简历项目中，我负责的是一个自动化代码审查 Agent。起初，我让它直接调用 GitLab API 去合并代码。结果第一次测试，它因为分不清“Feature Branch”和“Master Branch”的权限差异，差点把测试数据删掉。

教训很直观：没有权限隔离的 Agent，就是安全隐患。

工具调用：沙箱与权限的最小化原则

工具调用（Tool Calling）是 Agent 行动的手脚。在 Demo 里，我们喜欢让模型自由发挥，传入任意参数。但在生产中，必须建立严格的“白名单”机制。

1. 参数校验前置

不要信任模型生成的 JSON 参数。在代码层面，必须在模型输出后、工具执行前，进行二次校验。

import json from pydantic import BaseModel, Field class SearchArgs(BaseModel): query: str = Field(..., min_length=1, max_length=100, description="搜索关键词") limit: int = Field(default=5, ge=1, le=10, description="返回结果数量，最大10条") def execute_search_tool(raw_output: str): try: # 1. 解析 JSON parsed_data = json.loads(raw_output) # 2. Pydantic 强类型校验 args = SearchArgs(**parsed_data) # 3. 权限检查：限制只能搜索公开索引 if not is_public_index_allowed(args.query): raise PermissionError("无权访问该私有索引") return call_search_api(args.query, args.limit) except Exception as e: # 记录详细错误，便于后续调试 log_error(f"Tool Execution Failed: {e}", raw_output) return {"error": "工具执行失败，已记录日志"}

2. 失败恢复与熔断

当工具调用失败（如 API 限流、网络超时）时，Agent 不应该简单地重试，而应该触发“降级策略”。例如，如果外部搜索不可用，是否回退到本地缓存？如果还是不行，是否将任务挂起并通知人工介入？

在我的项目中，我们引入了一个简单的熔断器模式。当连续 3 次工具调用失败，Agent 停止执行，并将上下文打包发送给值班开发人员。这不仅保护了系统，还提供了一个宝贵的调试入口。

任务规划：从“一步到位”到“分步验证”

大型 LLM 在一次推理中处理复杂规划的能力是有限的。为了减少幻觉，我们将任务拆解为细粒度的步骤，并在每一步之后进行“自我反思”或“中间态检查”。

规划的可观测性

传统的规划是黑盒的。我们看到的只有最终结果。但为了解决“为什么错了”的问题，我们需要记录每一步的决策依据。

{ "step_id": "plan_001", "action": "call_tool", "tool_name": "code_review_diff", "arguments": {"repo": "project-x", "branch": "dev"}, "confidence_score": 0.92, "reasoning_trace": "用户要求审查最新提交，当前分支为 dev，故调用 diff 工具获取变更内容。", "timestamp": "2026-07-20T10:00:01Z" }

这种结构化的日志，不仅有助于调试，还能作为后续优化 Prompt 的依据。如果发现模型在某些类型的规划上总是出错，我们可以针对性地增加 Few-shot Examples 或调整 System Prompt 的语气。

记忆系统：状态即上下文

记忆（Memory）是 Agent 保持上下文连贯性的关键。但在工程中，我们必须区分“短期记忆”（会话上下文）和“长期记忆”（向量数据库）。

内存溢出与上下文窗口管理

很多开发者忽略了一个事实：LLM 的上下文窗口是有限的，而且越长，成本越高，延迟也越高。在我们的实践中，我们采用了“滑动窗口 + 摘要压缩”的策略。

当对话长度超过阈值时，我们不直接截断，而是对之前的对话进行摘要，保留关键事实和决策点。这既节省了 Token，又避免了信息丢失。

class MemoryManager: def __init__(self, max_tokens=4000): self.history = [] self.max_tokens = max_tokens def add_message(self, role, content): self.history.append({"role": role, "content": content}) def get_context(self, llm): total_tokens = sum(len(msg['content']) for msg in self.history) if total_tokens > self.max_tokens: # 触发摘要逻辑，这里简化为保留最近 N 条 self.history = self.history[-5:] return self.history