提示词是请求，而不是许可。这就是为什么你的智能体仍处于试点阶段。

我在这里不断看到同样的帖子，只是细节不同。语音智能体接真实预订，所有写在提示词规则里的护栏最终都被打破了。一个智能体编造了价格并通过邮件发给了客户。另一个对客户说可以购买公司并不销售的产品，而日志无法说明原因。有人发现他们的智能体可以无人值守地合并到主分支，却不能发送一封邮件，而且无法解释为什么这是正确的决定，只是觉得这样做是对的。这些都不是模型问题。你在要求你试图治理的对象去自我监督。系统提示词中的“绝不要报出你无法核实的价格”是一条请求。模型大多数时候会遵守。大多数时候恰恰是最糟糕的结果，因为两周之后你就不再检查了。对于我看到的大多数方案，我想反驳的一点是：检查必须放在工具边界，而不是放在指令里。如果超过500的退款需要人工处理，那应该存在于代码路径中，让智能体在物理上无法调用该端点。而不是放在提示词里，因为一个奇怪的客户对话轮次就能让它绕开规则。每一条提示词级别的规则都是一次胜率不错的抛硬币，而你在每个任务中要抛四十次。但这里几乎没人讨论的是三周后会发生什么。有人发帖说72%的团队在生产环境中运行智能体，而大多数团队无法说出对某个具体行为负责的人是谁。我觉得实际数字可能更高。法务部门或你的大客户问谁批准了这次退款，而“智能体决定的”会以糟糕的结局收场。很多团队当下把关是正确的，但事后仍然无法重建当时的决策过程。审批必须留下比会话存活更久的记录，理想情况下，你可以不依赖供应商仪表盘的说法来核验。这个差距才是试点无法落地的真正原因。不是准确性问题。没有人能回答谁对此负责。我想听听真正在运行这类系统的人怎么说：你们的强制检查到底在哪里，老实说。是提示词、框架回调，还是工具边界？你们是逐个操作审批，还是批量审批？批量审批正是我观察到的、人们在悄悄重新构建刚刚解决的问题的地方。一个月之后，你还能重建出谁批准了什么、以及智能体随后是否做了略微不同的事情吗？我全职做这方面的工作，所以你们可以自行权衡我的观点。欢迎在评论区问我任何问题。