一个 Demo Agent 和生产 Agent 可能调用完全相同的模型，差异却几乎都发生在模型之外。Demo 只需展示一条成功路径；生产系统必须面对模糊输入、工具故障、重复调用、权限边界、长尾成本和不可逆操作。
Vercel 的生产指南给出一个很实用的判断：Agent 适合路径会随请求变化、必须读取外部状态后才能决定下一步，而且错误容易撤销的任务。只要动作代价很高，Agent 的自由度就必须被工作流和审批重新包住。
#先确认为什么必须使用 Agent
聊天机器人通常只生成回答；工作流在代码中预先决定步骤，只在固定位置调用模型；Agent 则把“下一步做什么”交给模型，并在循环里动态调用工具。
这种动态性会增加延迟、成本和故障表面，所以它必须解决确定性工作流无法合理处理的问题。若任务步骤可以提前列清楚，就优先使用普通工作流；若只有一个环节需要探索，可以把 Agent 作为受限组件嵌入工作流，而不是让整条业务链都由模型控制。
一个简单判断式是：错误概率乘以恢复成本。Agent 可以处理高不确定但低恢复成本的研究、草稿和候选方案；发送、删除、发布和资金动作即使错误概率不高，也应因恢复成本过大而进入审批。
#第一步不是写提示词，而是定义“完成”
任务范围越窄，越容易建立可测标准。不要把“帮助客户解决问题”直接交给 Agent，而要说明它负责哪些请求、可以访问哪些数据、怎样算解决、何时必须升级给人类。
这些成功标准会直接变成评估集。先用最强模型证明任务在目标质量上可行，再比较更小、更快或更便宜的模型。排行榜只能提供候选，无法代替模型在真实工具循环和流量分布中的测试。
#工具定义就是权限设计
工具既是 Agent 的能力边界，也是副作用入口。每个工具应只暴露完成任务所需的最小操作，参数名与说明要像交给第一次接触系统的同事一样明确。查询上下文与产生副作用的动作应分开，避免一个模糊的“大工具”同时拥有读取、修改和删除能力。
工具数量也不是越多越好。模型会在相似工具之间混淆，复杂说明会占用上下文。只有评估证明单 Agent 无法稳定遵循指令，或经常选错相似工具时，才考虑拆分成多个专门 Agent。
#把护栏放在模型无法绕过的位置
不可逆操作需要在工具执行前暂停，并要求人类确认。参数 Schema、业务约束、身份权限和幂等检查应位于工具实现附近，而不是只写进系统提示词。提示词可以告诉模型不该做什么，代码必须确保它即使做出错误决定也无法越权。
生产循环还需要外部硬上限：最大步骤数、工具调用数、Tokens、墙上时间和总成本。不能依赖模型自己识别“已经卡住”，因为重复尝试往往正是失败模式。研究任务可以允许更多步骤，拥有发布或支付权限的 Agent 则应设置更紧上限。
#评估要覆盖真实路径和安全退出
小型评估集应尽早从真实运行轨迹中建立。每次提示词或工具变更都可能修好一个案例、破坏另一个；没有回归评估，只能凭 Demo 感觉判断。
评估不应只测最终答案，也要覆盖工具选择、权限拒绝、审批触发和上限停止。一个成熟用例至少证明：正常任务能够成功；危险请求被拦截；工具失败后不会无限重试；达到预算后能够干净结束；需要人类时会保存状态并正确恢复。
#成本单位应该是完成的任务
单次模型请求价格无法反映 Agent 经济性。一个业务结果可能包含规划、检索、工具重试、记忆写入和模型升级。更合理的计量单位是完整 agent_run_id：比较典型运行成本与高分位长尾，才能看出正常单元经济是否成立、哪些循环正在失控。
高分位比平均值更能暴露问题。少量卡住的任务可能消耗大部分预算；只有把所有调用关联到最终任务，工程与财务才会看到同一种成本。
#运行时要支持长任务，而不是延长 HTTP 请求
生产 Agent 可能跨越单次请求周期，也可能等待 Webhook 或人工审批。状态应持久化到可恢复工作流，每个完成步骤形成检查点，失败后从最近成功位置继续，而非从头重放所有模型调用。
用户界面还应持续展示当前进度、工具活动和待审批动作。长时间静默会让用户误以为系统卡死，也隐藏了 Agent 正在进行的高风险操作。若 Agent 生成或执行代码，独立沙盒与网络边界则是最低要求。
#上线标准是证据，不是演示效果
生产准备完成的信号，不是 Agent 在演示中连续成功三次，而是评估和日志共同证明它在真实路径上稳定：工具权限收紧，不可逆操作有审批，循环与费用有边界，失败能够恢复，长尾运行可以解释。
自主性不是一个开关，而是一笔按恢复成本分配的预算。越容易撤销的环节，可以交给模型更多空间；越难撤销的环节，越应该回到确定性代码与人类决策。这样构建的 Agent 不一定最炫，但它的错误会更便宜，也更接近真正可以长期运行的产品。