企业官网建设流程全解析

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”需要哪些模型之外的基础设施？

如果用一个比喻，基础模型本身像是一个刚毕业但自信心爆棚的实习生：脑子转得快、知识面广，但缺少流程、记录、工具和现场管理的加持时，很容易做出“看起来合理但经不起推敲”的事情。要让这个实习生独立负责一条业务线，你至少得给它配五样东西：控制循环与状态管理、上下文与记忆系统、工具接入与动作层、安全护栏与权限边界、可观测性与评测机制。前两样决定它“能不能想清楚并记住”，中间两样决定它“能不能安全地动手”，最后一样决定你“敢不敢让它上线”。

我见过不少项目把预算和精力几乎全花在“选最强的模型”上，等到系统跑到一半才发现连最基本的日志都没有，任务失败了完全不知道模型在哪里做错了判断。这也是为什么我对“模型本身解决一切”的说法很警惕。后面