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

别迷信全自动：把 Agent 接进生产前，我先砍掉了三个“想当然”

news 2026/7/19 16:36:38

聊《我把Agentic AI接进项目后，先推翻了几个想当然》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

摘要：很多人以为 Agentic AI 就是给 LLM 装上工具就能自动干活。我最近在重构一个自动化审批流时，发现 Demo 跑得再顺，一上生产就炸。真正的门槛不在 Prompt 编写，而在权限隔离、全链路日志和异常兜底。本文复盘了从“聊天机器人”到“自主执行系统”的工程化阵痛，分享那些没写在论文里的避坑指南。

最近圈子里 Agentic AI 很火，大家都在谈 autonomy（自主性）。我也按捺不住，把公司内部那个基于规则的老派自动化脚本，替换成了基于 LangGraph 的 Agent。起初我觉得这就像给旧车换个新引擎，插上线就能跑。结果上线第一天，Agent 擅自给三个非关键供应商发了加急邮件，导致后续流程混乱，运维团队差点把我拉黑。

这次事故让我清醒地认识到：从 Chatbot 到 Agentic System 的距离，不是算法的差距，而是工程严谨性的鸿沟。今天不聊虚的概念，聊聊我是怎么推翻几个“想当然”，才让 Agent 真正敢上生产的。

1. 自主性的边界：它不是许愿池，是实习生

刚接手这个项目时，我的第一反应是：“给模型一个高权限的工具列表，让它自己决定调用哪个。”这是典型的思维陷阱。

LLM 本质上是概率模型，它没有真正的“意图”，只有对下一个 token 的预测。如果你赋予它过高的自由度，它就会在看似合理的逻辑中产生“幻觉式执行”。

我的取舍：
我不追求 100% 的自主性，而是采用“人机协同的半自主模式”。

低危操作（如数据查询、格式转换）：允许 Agent 直接执行。
高危操作（如发送邮件、修改数据库、调用支付接口）：必须经过人工确认（Human-in-the-loop），或者由一个独立的“裁判模型”进行二次校验。

这种设计虽然牺牲了一点速度，但极大地降低了生产环境的风险。记住，自主性不等于失控，可控的自主才是工程化的起点。

2. 任务拆解：把“模糊指令”变成“确定图”

很多初学者直接用 Chain-of-Thought (CoT) 来解决复杂任务，但在实际工程中，CoT 的稳定性极差。随着步骤增加，错误率呈指数级上升。

我后来引入了 Graph-based 的工作流编排。与其让模型自由发挥，不如预先定义好状态转移图。

比如处理一个“报销审核”任务，我将其拆解为确定的节点：
1.parse_receipt: 解析发票图像
2.check_policy: 对照公司财务政策
3.detect_anomaly: 异常检测（如连号发票）
4.approve_or_reject: 最终决策

在这个过程中，每个节点都有明确的输入输出契约。即使某个节点失败，整个图也不会崩溃，而是可以跳转到特定的错误处理分支。

# 伪代码示例：定义一个具有容错能力的状态机节点 from langgraph.prebuilt import create_react_agent def secure_tool_call(tool_name, arguments): """ 在执行工具前增加安全钩子 """ # 1. 权限检查 if not current_user.has_permission(tool_name): raise PermissionError(f"User lacks permission for {tool_name}") # 2. 参数清洗与校验 safe_args = sanitize_arguments(arguments) # 3. 执行实际工具 return execute_tool(tool_name, safe_args) # 构建 Agent 时注入安全层 agent_executor = create_react_agent( model=llm, tools=[secure_tool_call], checkpointer=MemorySaver() # 支持中断和恢复 )

这段代码的核心不在于“能执行”，而在于在执行之前拦截风险。这就是 Demo 和生产环境的区别：Demo 关注成功率，生产关注失败后的表现。

3. 可观测性：没有日志的 Agent 就是黑盒

这是我最想强调的一点。在之前的项目中，我们只记录了最终的输出结果。当 Agent 出错时，我们完全不知道它是哪一步“想歪了”。

工程化改造：
我开始强制要求记录每个节点的 Trace ID、Input/Output以及Tool Call 的参数。特别是对于工具调用，必须记录“为什么调用这个工具”以及“工具的返回值是什么”。

我使用了 LangSmith 这类工具来可视化整个执行路径。有一次，我发现 Agent 总是错误地调用get_weather而不是get_stock_price，通过查看 Trace 日志，我发现是因为 Prompt 中把“天气”和“行情”的描述混淆了，导致模型在相似语义下产生了偏差。

如果没有这些细粒度的日志，调试 Agentic AI 无异于大海捞针。可观测性不仅是用来 Debug 的，更是用来优化 Prompt 和工具定义的反馈闭环。

4. 安全约束：给 AI 加上“脚镣”

很多开发者认为，只要 Prompt 写得足够好，就能防止 AI 泄露数据或执行危险操作。这是极其危险的错觉。

我的实践原则：

最小权限原则：Agent 使用的 API Key 必须限制在最小必要范围。例如，只读数据库的 Agent，绝不应该拥有写入权限。
输出过滤：在将 Agent 的输出返回给用户之前，必须经过一个严格的过滤器，检查是否包含敏感信息（如 PII、密钥、内部 IP）。
超时与重试限制：防止 Agent 陷入死循环。如果某个工具连续调用失败超过 3 次，或者执行时间超过 10 秒，必须强制终止并报警。

在一次压力测试中，我故意让 Agent 面对一个不断返回错误的 API。如果没有设置重试上限，Agent 会在几分钟内耗尽所有额度并触发云端计费警报。限制并发和频次，是保护钱包的最后防线。

5. 总结：从 Demo 到 Production 的最后一公里

Agentic AI 的价值毋庸置疑，但它不是一个“即插即用”的黑科技，而是一个需要精心呵护的工程系统。

回顾这次复盘，我最大的感触是：
1. 不要追求全自动：引入人为干预机制（Human-in-the-loop）不是倒退，而是为了更稳健的前进。
2. 结构化优于自由化：用 Graph 或 State Machine 约束模型的行为，比依赖 Prompt 的魔力更可靠。
3. 日志即生命：没有完善的可观测性，Agent 的生产部署就是赌博。

当你下次准备将 Agent 接入生产环境时，不妨先问自己三个问题：