首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >生产级 AI Agent 的难点不在“让它跑起来”,而在“让它一直跑对”。

生产级 AI Agent 的难点不在“让它跑起来”,而在“让它一直跑对”。

原创
作者头像
资源shanxueit.com
发布2026-08-23 12:00:03
发布2026-08-23 12:00:03
980
举报

一份来自 Gartner 的调研数据很能说明问题:截至目前,仅 17% 的组织部署了 AI Agent,但超 60% 计划在未来两年内完成部署。这道横亘在“Demo 成功”与“生产可用”之间的鸿沟,核心矛盾在于:大模型的概率本性,与业务系统对确定性的要求,天然冲突

下面,我们用少量代码,串联起跨越这道鸿沟的工程化方法论。


一、核心矛盾:为什么传统开发套路失效了?

传统软件是确定性系统:输入 A,输出 B。AI Agent 引入大模型后,带来了三个根本变化:

  1. 输出不确定:同样的问题,今天和明天的答案可能不同。
  2. Prompt 即代码,却无人管理:改一行代码要走评审,改一句 Prompt 可能让整个 Agent 行为大变,却没有任何工具能评估影响范围。
  3. 依赖项动态变化:大模型是云端服务,提供商悄悄升级,你的 Agent 表现可能就变了。

因此,传统的测试、发布、监控体系全都不适用了。生产级 Agent 的核心,是用一套工程化的手段,持续回答“它到底好不好”。


二、工程化铁律:少即是多,确定性归代码

在生产环境中,一个核心设计原则能避免大量问题:能用确定性代码解决的事,就别让大模型做

反模式:用 Prompt 让 LLM 输出 JSON,然后写代码解析。

代码语言:javascript
复制
# 脆弱的方式:在 Prompt 里硬编码 JSON 格式
prompt = """
分析以下文本,返回 JSON 格式:
{
   "sentiment": "positive/negative",
   "score": 0-100
}
"""

这种方式的缺点是:Prompt 稍微改动,输出格式就可能跑偏,解析代码随时崩溃。

生产模式:使用 Pydantic 等工具,在代码层强制结构化输出。

代码语言:javascript
复制
from pydantic import BaseModel
from typing import List

# 1. 定义严格的输出契约
class SentimentResult(BaseModel):
    sentiment: str  # 'positive' or 'negative'
    score: int       # 0-100

# 2. 在调用 LLM 时直接使用这个 Schema
# (以 Google ADK 为例,它会自动将 Schema 注入请求,并校验返回)
# result = await agent.run_async(prompt, output_schema=SentimentResult)

这种方式将“契约”从模糊的自然语言提示,转移到了运行时验证的 Python 对象上,保证了结构的完整性,消除了脆弱的自定义解析代码。

同样,获取当前日期、做数学计算、校验数据格式,都应该用一行 Python 代码搞定,而不是交给 LLM 去推理,既慢又贵还不稳定。


三、核心架构:从“黑盒循环”到“有状态机”

早期的 Agent 依赖简单的 ReAct 循环(思考-行动-观察)。但在生产中,这会导致上下文膨胀和规划短视。推荐采用“计划-执行-验证”(Plan-Execute-Verify)的状态机架构

代码语言:javascript
复制
from enum import Enum
from typing import List, Optional
from pydantic import BaseModel

# 1. 定义 Agent 的状态
class AgentState(str, Enum):
    PLANNING = "planning"   # 规划阶段
    EXECUTING = "executing" # 执行阶段
    VERIFYING = "verifying" # 验证阶段
    COMPLETED = "completed" # 完成
    ERROR = "error"         # 错误

class PlanStep(BaseModel):
    step_id: str
    description: str
    tool_name: str
    tool_args: dict

class AgentContext(BaseModel):
    session_id: str
    state: AgentState
    user_input: str
    plan: Optional[List[PlanStep]] = None # 显式的执行计划
    intermediate_results: dict = {}       # 中间结果存储
    final_answer: Optional[str] = None

# 2. 核心路由逻辑(伪代码)
def router(context: AgentContext):
    if context.state == AgentState.PLANNING:
        # 调用 LLM 生成 PlanStep 列表,而不是直接调用工具
        context.plan = planner_agent.plan(context.user_input)
        context.state = AgentState.EXECUTING
        return context
    elif context.state == AgentState.EXECUTING:
        # 按顺序或并行执行计划中的步骤
        execute_next_step(context) # 这里会调用具体工具
        context.state = AgentState.VERIFYING
        return context
    elif context.state == AgentState.VERIFYING:
        # 检查上一步执行结果是否符合预期
        if verify_step(context):
            # 继续执行或结束
            context.state = AgentState.COMPLETED if plan_is_done else AgentState.EXECUTING
        else:
            # 触发重规划(Re-planning),而不是直接报错
            context.state = AgentState.PLANNING
        return context

这种显式的状态管理,极大提升了长任务执行的稳定性和可调试性。


四、生产三件套:评估、可观测、成本控制

这三样是生产级系统与 Demo 的分水岭。

1. 评估先行(Evaluation) 把“评估”放在开发生命周期的起点。先定义“好”的标准,构建一套基准数据集(覆盖常见和边缘情况)。每次改动,都用同一套标准去衡量效果。团队启动项目时,第一个问题应是“我们要解决什么问题”,而不是“这个智能体能做什么”。

2. 可观测性(Observability) Agent 出错,不能只知道“错了”,要知道“错在哪一步”。从第一天就接入追踪,让 Agent 的每一步(调了什么模型、用了什么工具、传了什么参数)都结构化记录下来。一个 Trace ID 贯穿全链路,记录每个节点的状态、耗时和 Token 消耗。

代码语言:javascript
复制
# 简单的追踪装饰器思想
def trace_agent_step(func):
    async def wrapper(*args, **kwargs):
        step_id = generate_step_id()
        log_step_start(step_id, func.__name__, kwargs)
        try:
            result = await func(*args, **kwargs)
            log_step_end(step_id, result)
            return result
        except Exception as e:
            log_step_error(step_id, str(e))
            raise
    return wrapper

3. 成本与安全护栏 Agent 一旦接入真实业务,每个工具都需要权限边界、参数校验、幂等策略和失败回滚。必须建立“大模型网关”实现限流、熔断与多模型热切换。对于关键决策节点,强制设置人工审核(Human-in-the-Loop),这是避免灾难的最后防线。


总结

从 0 到 1 打通生产级 AI Agent,本质上是一次思维转变

  • “提示词工程”转向“状态机设计”
  • “关注模型能力”转向“关注评估体系”
  • “让模型做所有事”转向“让代码负责确定的事,让模型负责理解与生成”

市面上像 prodagent 这样的新框架,以及 Google ADK、LangGraph等,都在把这些“生产级铁律”做成框架的一等公民。但理解背后的工程逻辑,比掌握某个特定工具更重要——因为大模型会变,但工程化应对不确定性的原则不会变。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、核心矛盾:为什么传统开发套路失效了?
  • 二、工程化铁律:少即是多,确定性归代码
  • 三、核心架构:从“黑盒循环”到“有状态机”
  • 四、生产三件套:评估、可观测、成本控制
  • 总结
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档