智能体获救了，修复去向何处？
摘要
本文讨论了如何通过一个结构化流程将针对AI智能体的手动修复纳入未来的改进，以Reef的harness教程为例，该流程包括记录纠正、测试更改和发布版本。
智能体卡住了，有人手动修复了它，任务完成了。接下来值得修复的部分是这个纠正去向何处。如果它只留在某人的脑海里，下一次运行会得到同一个带有相同盲点的智能体。Reef的harness教程为这种反馈提供了一条回路：记录请求，在其收据上附加评分和纠正，让模型提出技能更改，然后在相同的任务上测试当前和更改后的harness，再发布版本。这仍然需要你定义一个好修复对你的工作流意味着什么，并实际安装所选版本。但人工干预可以成为下一次更改的输入，而不是在工单关闭时消失。如今你的手动修复最终去了哪里：一个运行日志、一个提示编辑，还是下一个版本真正测试的东西？
相似文章
什么能让你确信智能体真正修复了问题？
本文讨论了应使用什么标准来验证AI智能体对基础设施问题的修复，以Skyportal的智能体为例，展示了验收条件和检查方法。
你的 AI Agent 没坏，是你的控制框架没配好。来看看我是如何搭建这套系统，让它从“累赘”转变为能交付生产级代码的。
本文指出，AI 编程智能体的失败源于系统设计不佳，而非模型能力限制。文章提出了一套包含知识、护栏和反馈循环的三层“控制框架”，以可靠地交付生产级代码。
我的智能体修复了审查员标记的问题，但下一次审查却通过了修复引入的错误。
一个AI智能体使用子智能体来审查和修复生成幻灯片中的问题，但修复引入了新的错误，审查员未能发现，导致最终产品存在缺陷。
我的AI代理在不同会话间不断丢失自身状态，因此我选择重建工具链而非更换模型
作者发现AI代理的可靠性问题源于工具链而非模型，通过分离上下文跟踪、加载和输出检查来改进，同时致力于版本控制以管理跨项目的代码。
如何提高AI代理的可靠性？
讨论将AI代理从沙箱迁移到生产环境所面临的挑战，强调高敏感性导致大量噪声，并提出解决方案，如二级评估器、启发式方法和级联架构。同时向社区询问他们的过滤方法。