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

别急着造轮子：小团队做 Agentic AI，先搞定这三道“拦路虎”

news 2026/7/13 18:53:33

聊《Agentic AI真能提效吗？先看流程里最慢的那一步》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

摘要：最近行业里都在谈 Agent，但从 Demo 到生产环境，中间隔着权限管理、可观测性和安全约束三道坎。本文结合一线实战经验，分享如何在资源有限的情况下，避免过度设计，构建真正能“干活”的自主执行系统，而非只会聊天的聊天机器人。

Agentic 的定义：不止是 Prompt 的堆砌
自主性的边界：什么时候该让模型“闭嘴”
任务拆解：从线性思维到图结构
可观测性：没有日志的 Agent 就是黑盒
安全约束：给自由意志套上枷锁
总结：工程化优于算法创新

Agentic 的定义：不止是 Prompt 的堆砌

很多刚接触 Agentic AI 的朋友，第一反应是：“我是不是要把 Prompt 写得足够长，让模型知道每一步该干嘛？”

这是一个巨大的误区。Chatbot 的核心是“对话”，而 Agentic System 的核心是“行动”。

在早期的 RAG（检索增强生成）应用中，我们解决的问题是“模型不知道什么”。而在 Agentic 范式中，我们要解决的是“模型能做什么”以及“做得对不对”。如果你仅仅把 LLM 当作一个更聪明的搜索框，那你并没有进入 Agent 的世界。

真正的 Agentic 定义，应当包含三个要素：感知（Perception）、规划（Planning）、行动（Action）。

感知：不仅仅是读取用户输入，还包括读取当前系统状态、数据库快照、API 返回值。
规划：面对一个模糊的目标（如“帮我优化一下服务器性能”），模型需要将其拆解为具体的子任务（检查 CPU、检查磁盘 I/O、分析慢查询）。
行动：调用工具执行操作，并根据反馈修正下一步计划。

我在上一个项目中，曾尝试用一个简单的 Chain 结构来处理客服工单分类。结果发现，当遇到歧义工单时，模型直接给出了错误分类，因为 Chain 是线性的，无法回溯。后来引入 ReAct（Reasoning + Acting）框架，让模型在每次调用工具前输出思考过程，准确率才从 65% 提升到了 88%。

所以，别急着写复杂的 Prompt，先想清楚你的系统是否具备了“感知-规划-行动”的闭环能力。

自主性的边界：什么时候让模型“闭嘴”

这是我在真正跑起来中最常踩的坑：过度信任模型。

在 Demo 阶段，你希望 Agent 越聪明越好，它能自动修复 Bug、自动部署代码、甚至自动发送邮件。但在生产环境中，这种“全权委托”是灾难性的。

我们需要为 Agent 划定明确的自主性边界。

1. 只读权限 vs 写入权限：对于分析类任务，Agent 可以拥有数据库的只读权限，用于查询数据。但对于涉及资金、用户隐私或核心配置的操作，必须切断 Agent 的直接写入权限，转而通过“人类确认”机制（Human-in-the-loop）来完成。
2. 工具调用的白名单：不要让模型自由选择所有可用的 API。你应该提供一个严格的工具集（Tool Set），并且每个工具都要有明确的输入输出 Schema。

举个例子，我有一个负责运维监控的 Agent。它可以通过check_disk_usage工具查看磁盘空间，但如果它发现磁盘快满了，它不能直接执行rm -rf /tmp/*。它会生成一个建议：“检测到 /tmp 目录下文件占用超过 90%，建议清理，是否执行？”然后等待人工点击“确认”。

这种克制，不是能力的不足，而是工程的成熟。

任务拆解：从线性思维到图结构

线性工作流（Linear Workflow）在处理简单任务时很有效，比如：用户提问 -> 检索知识库 -> 生成回答。

但当任务复杂度上升，比如“根据上周的销售报表，找出销量下降的前三名商品，并生成营销邮件草稿，最后发给市场部负责人”，线性链就会崩溃。因为中间的任何一步出错，整个流程都会中断，且难以局部重试。

这时候，你需要引入图结构（Graph-based）的工作流引擎，如 LangGraph 或 Durable Functions。

在图结构中，任务不再是单向流动，而是存在节点（Node）和边（Edge）。节点可以是模型推理、工具调用或人工审核；边则定义了流转逻辑，包括条件分支、循环和错误恢复。

from langgraph.graph import StateGraph, END # 定义状态 class AgentState(TypedDict): question: str intermediate_steps: List[Dict] final_answer: str # 定义节点 def plan_step(state: AgentState) -> AgentState: # 这里是大模型的规划逻辑 return {"intermediate_steps": [...]} def execute_step(state: AgentState) -> AgentState: # 执行具体工具 return state # 构建图 workflow = StateGraph(AgentState) workflow.add_node("planner", plan_step) workflow.add_node("executor", execute_step) # 设置入口和出口 workflow.set_entry_point("planner") workflow.add_edge("planner", "executor") workflow.add_edge("executor", END) app = workflow.compile()

这种结构让你的 Agent 具备了“弹性”。如果执行步骤失败，你可以选择重试、回退到规划步骤重新拆解，或者抛出异常让人工介入。这才是生产级 Agent 该有的样子。

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

“为什么我的 Agent 这次回答得好，下次就答错了？”

这是所有 Agent 开发者都会遇到的问题。由于 LLM 的非确定性（Temperature > 0），同样的输入可能产生不同的输出轨迹。如果没有完善的可观测性（Observability），你根本无法排查问题。

在传统的软件工程中，我们有 Stack Trace。在 Agentic 系统中，你需要记录的是Trace，即 Agent 的完整决策链路。

你需要记录：
1. Input：用户的具体请求。
2. Thought Process：模型在每个步骤中的思考过程（如果是 ReAct 模式）。
3. Tool Calls：调用了哪个工具，传了什么参数，返回了什么结果。
4. Latency & Cost：每个步骤耗时多少，Token 消耗多少。

我推荐使用 LangSmith 或 Arize Phoenix 这样的工具来可视化这些 Trace。在一次事故排查中，我们发现某个 Agent 频繁超时，通过 Trace 发现，它在调用外部 API 前，会错误地重复解析两次 JSON 数据，导致额外的 Token 消耗和延迟。如果没有可视化的 Trace，这种问题几乎不可能被发现。

可观测性不仅是排障工具，更是优化 Agent 性能的仪表盘。通过分析 Trace 数据，你可以识别出哪些步骤是瓶颈，哪些工具调用是多余的，从而进行针对性的优化。

安全约束：给自由意志套上枷锁

Agentic AI 的强大在于它的自主性，但风险也源于此。一旦 Agent 获得了访问生产环境的权限，它就可能成为攻击者的跳板。

除了前面提到的权限隔离，还需要在代码层面实施严格的安全约束：

1. 输入净化：用户输入可能包含恶意指令（Prompt Injection）。在将输入传给 LLM 之前，必须进行清洗和校验。
2. 输出过滤：模型生成的工具调用参数，必须符合严格的 Schema。例如，如果工具要求传入一个整数 ID，绝对不能接受字符串或其他类型。
3. 沙箱执行：涉及代码执行的 Agent，必须在隔离的沙箱环境中运行，限制其网络访问、文件读写和进程创建权限。

不要指望 LLM 本身具备安全意识。它只是一个概率模型，不会理解“安全”的含义。安全必须是系统工程的一部分，是你在架构设计时就考虑进去的约束条件。