
一份来自 Gartner 的调研数据很能说明问题:截至目前,仅 17% 的组织部署了 AI Agent,但超 60% 计划在未来两年内完成部署。这道横亘在“Demo 成功”与“生产可用”之间的鸿沟,核心矛盾在于:大模型的概率本性,与业务系统对确定性的要求,天然冲突。
下面,我们用少量代码,串联起跨越这道鸿沟的工程化方法论。
传统软件是确定性系统:输入 A,输出 B。AI Agent 引入大模型后,带来了三个根本变化:
因此,传统的测试、发布、监控体系全都不适用了。生产级 Agent 的核心,是用一套工程化的手段,持续回答“它到底好不好”。
在生产环境中,一个核心设计原则能避免大量问题:能用确定性代码解决的事,就别让大模型做。
反模式:用 Prompt 让 LLM 输出 JSON,然后写代码解析。
# 脆弱的方式:在 Prompt 里硬编码 JSON 格式
prompt = """
分析以下文本,返回 JSON 格式:
{
"sentiment": "positive/negative",
"score": 0-100
}
"""这种方式的缺点是:Prompt 稍微改动,输出格式就可能跑偏,解析代码随时崩溃。
生产模式:使用 Pydantic 等工具,在代码层强制结构化输出。
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)的状态机架构。
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 消耗。
# 简单的追踪装饰器思想
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 wrapper3. 成本与安全护栏 Agent 一旦接入真实业务,每个工具都需要权限边界、参数校验、幂等策略和失败回滚。必须建立“大模型网关”实现限流、熔断与多模型热切换。对于关键决策节点,强制设置人工审核(Human-in-the-Loop),这是避免灾难的最后防线。
从 0 到 1 打通生产级 AI Agent,本质上是一次思维转变:
市面上像 prodagent 这样的新框架,以及 Google ADK、LangGraph等,都在把这些“生产级铁律”做成框架的一等公民。但理解背后的工程逻辑,比掌握某个特定工具更重要——因为大模型会变,但工程化应对不确定性的原则不会变。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。