1. 先想明白模型能力不等于系统能力Agent 和模型的分界线在哪里如果只看今年的技术热词你很容易产生一种错觉Agent 已经是成熟的软件形态只要把大模型 API 接上再套一层循环一个能自己收集信息、自己写代码、自己操作软件的“数字员工”就诞生了。我过去半年在真实项目里和 Agent 缠斗下来感受恰恰相反从模型到真正能用的 Agent中间不是隔着一个循环而是隔着一张很长的账单——记忆怎么存、工具怎么接、出错怎么恢复、权限怎么控制、表现怎么评估每个问题都能把一个炫酷 Demo 拉回现实。这篇文章我不打算讲某个具体框架因为你下周很可能就会换框架我想聊的是“把模型调用升级成真正的 Agent”这个过程中当前阶段最值得提前解决的 20 个问题。我尽量按自己帮客户评审 Agent 架构、以及亲手搭建 Agent 项目时反复遇到的共性问题来展开。如果你正在从 PoC 走向生产或者刚被老板分配了“研究一下 Agent”的任务这份问题清单可以直接拿来当自检表用。1.1 问题 1模型更强Agent 就一定更强吗先泼一盆冷水模型能力变强Agent 系统的上限确实会被抬高但下限不会自动被托住。很多人拿到新一代模型后第一件事就是跑一轮 benchmark然后问“它能做 Agent 吗”。这个问题把概念混淆了——你测的是模型的单步智力而 Agent 的价值是能在多步、多工具、有状态的真实环境里稳定完成目标。举个最直观的例子假设一个任务需要连续 5 步正确操作才能完成。如果某个模型的单步成功率是 80%那么理论上整条链路成功率只有 0.8 的 5 次方约 32.8%。换一个更强的模型单步成功率升到 90%链路成功率也只是 59%。放到生产环境里这依然意味着五次任务里有两次会失败。真正决定交付质量的是那 40% 的失败路径上系统有没有重试机制、有没有状态恢复、有没有让用户能理解发生了什么。所以我的观点很明确模型升级是“加分项”系统韧性是“必选项”。1.2 问题 2你要的是 Agent还是高确定性的 Workflow另一个高频混淆点是 Agent 和 Workflow 的边界。现在很多团队评估流程是这样的看到新模型很强就打算把所有业务流程都改成“让模型自由发挥”然后称之为 Agent 化。但在工程里Agent 的核心特征是“自主决策”也就是说它会产生无法提前枚举的路径Workflow 的核心特征是“路径确定”输入输出、流转条件都在代码里写死了。如果业务本来就是固定的“读取数据—提取信息—写入系统—结束”那它应该被做成 Workflow而不是套一个 Agent 外壳。把这两者分开不是学术洁癖而是直接决定你要不要背上状态管理和错误恢复这两座大山。路径确定时你只需要处理异常分支路径不确定时你就要处理“Agent 在第五步擅自换了一个做法”的情况。你还要能向用户解释它为什么这么干。否则用户问“为什么我的订单状态被改了”你只能回答“模型自己这么想的”这显然不能交付。社区里讨论 skill 和 agent 的区别时其实也是在说同一件事技能是可复用的确定性动作Agent 是决定何时启用这些技能的主体。你要先回答产品里哪些动作可以被枚举哪些动作必须留给 Agent 判断。1.3 问题 3一个“真正的 Agent”需要哪些模型之外的基础设施如果用一个比喻基础模型本身像是一个刚毕业但自信心爆棚的实习生脑子转得快、知识面广但缺少流程、记录、工具和现场管理的加持时很容易做出“看起来合理但经不起推敲”的事情。要让这个实习生独立负责一条业务线你至少得给它配五样东西控制循环与状态管理、上下文与记忆系统、工具接入与动作层、安全护栏与权限边界、可观测性与评测机制。前两样决定它“能不能想清楚并记住”中间两样决定它“能不能安全地动手”最后一样决定你“敢不敢让它上线”。我见过不少项目把预算和精力几乎全花在“选最强的模型”上等到系统跑到一半才发现连最基本的日志都没有任务失败了完全不知道模型在哪里做错了判断。这也是为什么我对“模型本身解决一切”的说法很警惕。后面