聊《一次Agent项目复盘问题最后出在流程而不是模型》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。上周组里引入了一套基于 LangGraph 的 AI 代码审查 Agent初衷很简单让 LLM 自动 Review PR减少人工重复劳动。结果上线一周不仅没提效反而成了新的“Bug 制造机”。我们原本以为Agent 的强大在于“思考”于是拼命堆砌 Prompt 里的推理步骤试图让它像资深架构师一样逻辑严密。但现实狠狠打脸当 Agent 从一个人对着屏幕敲代码变成要在 CI/CD 流水线里与几十个其他服务对话时模型本身的智商不再是瓶颈工具调用的稳定性、记忆的上下文污染、以及任务规划的鲁棒性成了决定生死的三道坎。今天不聊虚的直接复盘这次从 Demo 跑通到生产翻车的全过程重点讲讲工具调用、记忆管理和任务规划这三个核心组件在规模化协作中是如何拖后腿的以及我们最后是怎么修好的。目录规划能力从“线性脚本”到“动态图”的阵痛工具调用参数校验是最后的防线记忆系统Scoped Memory 避免上下文污染失败恢复给 Agent 一个“冷静期”总结规划能力从“线性脚本”到“动态图”的阵痛很多初学者写 Agent喜欢用 Chain-of-Thought (CoT) 硬编码流程。比如接收需求 - 搜索代码 - 生成修改建议 - 提交 PR。这在单人 Demo 里很完美因为假设了每一步都能成功且依赖关系固定。但在团队协作中这种线性思维是灾难性的。真实场景死锁的 Review 流程我们的第一个版本就是典型的线性链。Agent A 负责找 BugAgent B 负责修复。如果 Agent A 没找到 Bug它应该直接结束。但我们的代码逻辑里B 总是等待 A 的输出导致空指针异常或者无限重试。核心教训 Agent 不是脚本它是带有状态的决策实体。你需要的是图Graph而非链Chain。在使用 LangGraph 重构时我们将流程改为有向无环图DAG并引入了条件边Conditional Edits。只有当confidence_score 0.8时才触发修复节点否则直接进入“人工复核”节点。from langgraph.graph import StateGraph, END def review_code(state): # 模拟 LLM 评估代码质量 score llm.evaluate(state[pr_content]) return {score: score} def should_fix(state): if state[score] 0.8: return fix_code elif state[score] 0.5: return human_review else: return END workflow StateGraph(AgentState) workflow.add_node(review, review_code) workflow.add_conditional_edges( review, should_fix, { fix_code: fix_code_node, human_review: human_review_node, } )这种取舍在于你愿意牺牲多少自动化率来换取稳定性 早期我们追求 100% 自动结果 20% 的错误修复比手动改还慢。后来我们接受“二八原则”只处理高置信度的简单 Case复杂的交给人类效率反而提升了 3 倍。工具调用参数校验是最后的防线工具调用Function Calling是 Agent 的手脚。在 Demo 里我们通常只传一个简单的 JSON 字符串给 LLM让它决定调用哪个函数。但在生产环境中LLM 是会犯错的而且经常犯低级错误。踩坑记录幻觉导致的参数缺失有一次Agent 需要调用内部 Git 接口查看文件历史。Prompt 里写着“请获取 commit_id 为 abc123 的文件变更。”结果 LLM 生成的调用参数里commit_id变成了null或者格式变成了[abc123]而不是字符串。如果直接把这些参数传给后端 API轻则报错重则因为缺少校验引发安全漏洞或数据不一致。解决方案强制 Schema 校验 自动重试我们不能信任 LLM 输出的任何原始 JSON。必须在工具执行前加一层严格的 Pydantic 模型校验。如果校验失败捕获异常将错误信息反馈给 Agent让它自行修正并重试。from pydantic import BaseModel, Field class GitFetchParams(BaseModel): repo_name: str Field(..., descriptionRepository full name) commit_hash: str Field(..., patternr^[a-f0-9]{40}$, descriptionGit hash) def fetch_commit(params_dict: dict): try: validated_params GitFetchParams(**params_dict) except ValidationError as e: # 关键不要直接报错退出而是告诉 Agent 哪里错了 return { error: Parameter validation failed, details: e.errors(), retry_hint: Please check the format of commit_hash and repo_name. } # 执行实际逻辑 return execute_git_api(validated_params)这一步看似啰嗦却是从“玩具”到“产品”的分水岭。记住工具调用的核心不是“能不能调”而是“调错了怎么救”。记忆系统Scoped Memory 避免上下文污染这是最容易忽视的一点。在多人协作场景中Agent A 在处理 Jira Ticket #101 时产生的中间状态可能会泄露给处理 Ticket #102 的 Agent B。这就是所谓的“上下文污染”。策略按会话隔离 摘要压缩我们最初使用的是全局向量数据库存储所有知识导致每次查询都要检索大量无关信息既慢又容易干扰决策。后来我们做了两个关键改动1. Session Isolation会话隔离每个用户或每个 PR 拥有独立的 Memory Store。Agent 在规划任务时只能看到当前上下文的历史记录。2. Summarization摘要压缩当对话轮数超过一定阈值比如 10 轮不再保留原始对话而是通过一个小模型生成一段“当前任务摘要”存入持久化记忆。class MemoryManager: def __init__(self, session_id: str): self.session_id session_id self.history [] def add_message(self, role: str, content: str): self.history.append({role: role, content: content}) # 触发摘要逻辑 if len(self.history) 10: self._summarize_and_compress() def _summarize_and_compress(self): # 调用轻量级模型生成摘要 summary llm.generate_summary(self.history) # 替换历史记录只保留关键事实和摘要 self.history [ {role: system, content: fHistorical Summary: {summary}} ] self.history[-5:] # 保留最近5轮细节这种取舍在于延迟 vs 准确性。压缩记忆会丢失细微的语气和边缘案例但对于大多数工程任务来说核心逻辑和事实才是最重要的。失败恢复给 Agent 一个“冷静期”在复杂的工作流中失败是常态。与其让 Agent 陷入死循环比如一直尝试修复同一个无法修复的 Bug不如设计一个显式的失败处理节点。我们的最终方案我们在图中增加了一个ErrorHandler节点。当某个工具调用失败超过 3 次或者置信度持续低于阈值时流程强制中断并将当前状态、错误日志和最近一次的对话快照打包发送给 Slack 频道或 Jira 工单。这不仅是容错更是可观测性的来源。通过收集这些失败案例我们可以反过来优化 Prompt 和工具定义。总结回到开头的问题为什么工具很火团队效率却没提升因为我们往往高估了 LLM 的“智能”而低估了工程的“严谨”。Agent 的核心原理——规划、工具调用、记忆本质上是在构建一个受控的、可观测的、具有容错能力的自动化流水线。1. 规划要灵活用图结构代替线性链条明确分支和终止条件。2. 工具要健壮严格校验输入建立自动重试和错误反馈机制。3. 记忆要隔离避免上下文污染适时进行摘要压缩。4. 失败要可见建立明确的降级策略和人工介入通道。不要指望写出一个“全自动”的 Agent 就能解决所有问题。相反承认 Agent 的不确定性通过工程手段去约束它才是从 Demo 走向生产的关键一步。下次当你准备引入 AI 编程工具时先问问自己我的权限隔离做了吗我的全链路日志清晰吗如果这两个答案是 No那么再完美的 Prompt 也只是空中楼阁。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
