前段时间我在给一个企业 AI 助手接入待办工具时遇到了一个很有代表性的问题。用户说帮我创建一个明天下午三点提交周报的待办。Agent 很快回复“好的已为你创建明天下午三点提交周报的待办。”从对话上看它理解了任务时间和内容也都没错。但我打开后台日志后发现待办其实没有创建成功。原因并不复杂模型传给接口的时间是明天下午3点而后端只接受类似2026-07-19T15:00:0008:00的标准时间格式。这次问题让我意识到Agent 在语言上理解正确不代表它在系统中执行正确。我的第一反应继续改 Prompt最开始我采用了一个很自然的办法——在系统提示词里补充规则调用待办创建工具时必须将时间转换为 ISO 8601 格式不得使用“明天”“下午”等自然语言。修改以后大部分请求正常了。但换几种说法问题又会出现“下班前提醒我发邮件”“月底之前提交报表”“两个小时后提醒我开会”。模型有时无法确定具体时间有时会自行补全接口调用失败后它还可能自动重试生成两条相同的待办。问题显然不只是 Prompt 写得不够长。Prompt 可以告诉模型“应该怎么做”却很难保证它“每一次都这样做”。模型输出带有概率性而业务接口要求字段齐全、类型正确、时间可解析并且请求不能重复执行。把这些要求全部压在 Prompt 上实际上是让概率系统承担确定性校验的职责。在 Prompt 之外加上四层保护后来我把待办创建链路拆成了四层。1. 用 Schema 限制工具参数与其在提示词里反复强调字段格式不如直接定义结构化参数{ title: 提交周报, dueTime: 2026-07-19T15:00:0008:00, timezone: Asia/Shanghai }其中title和dueTime是必填项dueTime必须满足指定格式从而在调用接口前挡住字段缺失和类型错误。不过Schema 只能保证“长得像合法参数”。模型生成一个已经过去的时间格式上仍然可能完全合法。2. 在业务层做二次校验因此调用接口前还要检查时间是否可解析、是否早于当前时间、时区是否明确以及标题是否为空。对于“下班前”“月底”这类存在歧义的表达我不再让模型猜而是让 Agent 向用户确认。少执行一次总比自信地创建一条错误待办更好。3. 把执行结果重新交给 Agent工具调用失败后不能只返回一句create todo failed。我会把可处理的错误原因告诉 Agent例如dueTime 早于当前时间请重新解析用户表达如果无法确定请向用户确认。Agent 据此决定修正参数、询问用户或终止任务避免接口已经失败它却仍然回复“创建成功”。4. 用幂等机制防止重复创建最后一层是幂等控制。系统为同一个创建请求生成稳定的请求标识。即使模型重试或网络超时后端也只允许创建一次。这一点很容易被忽略。Agent 的重试能力看起来很智能但只要工具会产生真实副作用——创建待办、发送邮件、提交审批——重试就必须和幂等一起设计。Prompt 很重要但它不是最后一道防线经历这次问题后我仍然重视 Prompt。它能帮助模型选择工具、理解字段并减少无效调用但我不再把系统可靠性寄托在它身上。在我看来Prompt 更像是给 Agent 的工作说明而 Schema、参数校验、执行反馈和幂等控制才是保证工作真正落地的安全网。当 Agent 开始操作真实系统后一次错误调用就可能创建重复数据、发错消息甚至触发无法撤销的业务流程。Agent 工程化真正困难的地方不是让模型“看起来会做”而是让系统在它偶尔判断错误时依然安全、可控。Prompt 决定了 Agent 如何思考工程系统决定了它能否可靠行动。