Marico's space

最近折腾了几个 AI Agent 项目，上线三周后无一例外都出了问题：模型在输出幻觉内容、边界情况处理得一塌糊涂、团队不得不人工审核所有产出。

这是 2026 年最常见的 AI Agent 部署剧情。原因不在模型本身——而是围绕模型构建的系统压根没考虑过生产环境的真实情况。

先说结论：大多数生产环境失败都来自三个根源：在 Agent 还没准备好时就把它当成开放式推理系统使用、跳过高风险操作的人工审批环节、以及除了最终输出外没有任何可观测性。真正有效的模式是：约束型工作流、显式审批门、以及完整的执行链路追踪。

为什么 Demo 会骗人

Demo 运行的是：

• 精心调优的提示词（Happy Path）
• 干净的数据
• 短时会话
• 已知工具
• 低风险输出

生产环境把这些全换了：

• 你从未预料到的用户长尾意图
• API 失败和限流
• 长会话下的上下文漂移累积
• 工具权限边界
• Agent 犯错后的真实后果

# Demo 测试的
test_cases = ["example_1", "example_2", "example_3"] # 3 条 Happy Path

# 生产环境面对的
production_inputs = real_user_data # 成千上万你从未想过的边界 case

这两行代码之间的差距，就是大多数 Agent 翻车的地带。

模式一：约束型工作流，而非开放式自主

最可靠的生产级 Agent，往往是那些自主权最少的。

听起来反直觉。但开放式"你自己看着办"的 Agent，在模型推理偏离预期结果的情况下会不断失败。而用确定性控制流约束的 Agent——LLM（大语言模型）只在定义好的工作流内处理有限任务——可靠性要高得多。

从左到右的演进光谱：

Level 1: 固定流水线
LLM 处理输入 → 结构化输出 → 下一节点
适用场景：分类、提取、摘要 Level 2: 条件路由
LLM 根据输入在预设路径中做选择
适用场景：分诊、路由、升级决策 Level 3: 带约束的工具调用 Agent
LLM 从定义好的工具集中选择，工作流有检查点
适用场景：研究、有边界的复杂任务 Level 4: 自主 Agent
LLM 自行规划执行，最小约束
适用场景：只有 Level 1-3 验证可靠后才考虑

大多数团队在生产环境直接跳到 Level 4。这就是他们失败的原因。

# 用 LangGraph 实现 Level 3 示例
from langgraph.graph import StateGraph workflow = StateGraph(AgentState)
workflow.add_node("classify_input", classify_node)
workflow.add_node("route_decision", route_node)
workflow.add_node("execute_tool", tool_node)
workflow.add_node("human_review", review_node) # 输出前的关卡
 # 条件路由——而非开放式推理
workflow.add_conditional_edges( "route_decision", lambda state: "human_review" if state["risk_level"] == "high" else "execute_tool"
)

模式二：显式人工审批门

问题不在于要不要加人工审批——而是什么操作需要审批。

# 给每个 Agent 操作映射风险等级
action_risk_map = { # 低风险——自主执行
 "search_web": "auto", "summarize_document": "auto", "classify_ticket": "auto", # 中风险——记录并监控
 "update_internal_record": "log", "draft_internal_message": "log", # 高风险——必须人工审批
 "send_external_email": "approve", "update_customer_record": "approve", "execute_financial_action": "approve", "delete_any_data": "approve", # 绝不允许自主执行
 "legal_advice": "block", "medical_recommendation": "block", "hiring_decision": "block"
}

审批门应该让审核人看到：

1. Agent 打算做什么
2. 它用了什么证据做出这个决定
3. 一份 30 秒内能看完的简明摘要
4. 明确的批准/拒绝/修改操作界面

# 好的审批门实现
def create_approval_request(agent_action, evidence, summary): return { "proposed_action": agent_action, "evidence_used": evidence[:3], # 取前 3 条来源
 "one_line_summary": summary, "risk_level": action_risk_map[agent_action["type"]], "timestamp": datetime.now(), "expires_at": datetime.now() + timedelta(hours=4) } # 把每次决策都记下来作为评估数据
def record_approval_decision(request_id, decision, reviewer_notes): # 这些数据会让 Agent 越用越强
 evaluation_store.append({ "request_id": request_id, "decision": decision, # approve / reject / edit
 "notes": reviewer_notes })

模式三：完整的执行可观测性

"Agent 给出了错误答案"根本不是有用的错误报告。你需要知道是哪一步出了问题。

# 每次执行需要追踪的内容

execution_trace = { "session_id": str(uuid4()), "input": original_user_input, "steps": [ { "step": 1, "type": "retrieval", "query": retrieval_query, "sources_retrieved": source_list, "latency_ms": 340 }, { "step": 2, "type": "llm_call", "model": "claude-sonnet-4", "prompt_tokens": 1240, "completion_tokens": 380, "latency_ms": 890, "output_summary": "分类为高风险，已路由至审批" }, { "step": 3, "type": "tool_call", "tool": "send_email", "result": "pending_approval", "approval_request_id": "req_abc123" } ], "final_output": agent_output, "total_latency_ms": 1230, "total_cost_usd": 0.0034, "success": True
}

生产环境真正需要关注的核心指标：

production_metrics = { # 质量
 "task_success_rate": "无需人工纠正即正确完成的任务占比", "first_pass_success": "无需返工或重跑的占比", "tool_selection_accuracy": "为任务类型选对工具的占比", # 安全
 "human_escalation_rate": "路由至人工的占比（应该随时间下降）", "policy_violation_rate": "被拦截的违规操作占比", # 运维
 "latency_p95": "P95 执行耗时", "cost_per_task": "总成本 / 已完成任务数", "error_rate": "以错误告终的执行占比"
}

如果第一天就没有追踪这些指标，你根本不知道自己的 Agent 是在变好还是在变烂。

发布门

在提示词、工具或模型的任何改动上线之前：

release_checklist = { "regression_tests_passed": True, # 相同输入 → 相同输出？
 "adversarial_tests_passed": True, # 边界 case 都处理了？
 "human_escalation_rate_acceptable": True, # 没有把所有请求都推给人工？
 "cost_within_budget": True, # 没有意外的 Token 爆炸？
 "latency_within_sla": True, # 没有性能回退？
 "approval_rate_unchanged": True # 人工审批率保持在正常水平？
} # 全部为 True 才发版
if all(release_checklist.values()): deploy_to_production()
else: block_deployment(release_checklist)

这个门能防止最常见的生产事故：团队出于好意改了提示词，结果把一类他们没测过的输入搞坏了。

说点实在的

大多数 AI Agent 在生产环境失败，不是因为模型不行——是因为围绕模型构建的架构没有考虑生产环境的真实情况。

Demo → 优化的是 Happy Path
生产 → 必须处理 Happy Path 以外的一切 差距在于：
- 约束型工作流（而非开放式自主）
- 人工审批门（而非全自动化）
- 完整可观测性（而非只看最终输出）

先把这两件事做好，再去操心选什么模型、怎么调提示词。那些东西没有这三样基础支撑，调了也是白搭。