Agent 出错了，很多团队的第一反应都是：改 Prompt，加 Skill。

模型参数写错了，加一句“严格按照 Schema 调用工具”；订单对象搞混了，加一句“请确认商品属于对应订单”；流程走错了，再补一条规则。
最后 System Prompt 越写越长，Agent 却不一定更稳定。

Airbnb 的新论文《Beyond Prompts: Measuring and Optimizing LLM Tool-Agent Harnesses》，提出了一个方向：Agent 的错误，不应该都让模型自己解决。

他们提出的 PRISM，会分析 Agent 的失败轨迹，再判断问题到底应该修在哪里：是 Prompt，还是 Harness 中的 middleware，或者两者一起改。

比如模型把工具参数 math_expression 写成 expression。
这不是模型不懂业务，而是接口格式错误。与其反复提醒模型，不如直接在工具执行前做确定性修正。

再比如，Agent 把订单 A 的商品拿去操作订单 B。
系统明明已经知道“订单—商品”的对应关系，那就应该在 Harness 层校验。如果对象不匹配，直接阻止执行，再把错误反馈给 Agent。

论文背后其实有一个很清晰的原则：Prompt 负责策略，Harness 负责约束。

接下来 Agent 真正进入生产环境以后，更重要的问题会变成：错误应该修在哪一层？什么事情应该让模型判断？什么事情应该由系统保证？

一个成熟的 Agent，不是拥有一个越来越长的 System Prompt。而是知道：什么事情值得让模型思考，什么事情根本不应该让模型有机会犯错。

#Agent #AIAgent #Harness #PromptEngineering #AgentEngineering #Airbnb #人工智能 #AI反常识howto