当天最强的证据把大型语言模型（LLM）代理当作需要受管权限、诊断和复核路径的系统。Agent Operating Systems、Type-Error Ablation 和 Monitoring Agentic Systems 给出的信号最清楚：可靠性取决于执行控制和反馈质量，也取决于模型输出本身。
Agent Operating System（AOS）论文给出了这一时期最明确的系统方案。它定义了一个面向长期运行代理的控制层，把身份、目标、任务图、能力、记忆、策略检查和审计记录都当作受管理对象。核心设计规则是在副作用操作执行前先获得确定性的批准，并把策略结果写入仅追加日志。
DevArch 以产品形态展示了同样的压力，面向 Claude Code。它用钩子、指令、架构决策记录、会话摘要、领域边界和测试门槛，把代理工作限制在项目规则内。证据是描述性的，没有基准或缺陷率测量，所以这里的实际主张是工作流形态，而不是可测的质量提升。
监控工作正变得更偏运维。audit-agent 研究认为，在任务级错误检测可靠之前，早期系统需要先检查集成缺口、阶段行为和跨运行差异。在它的合成审计测试台上，单次运行内监控发现了 CV = 0.02 的确定性阶段缺陷，跨运行监控发现了 CV = 1.25 的可变失败，结构监控发现了 CV = 0.00 的集成缺口。
分流结果很具体。该方法把 10,210 条 L3 发现送入自动监控，把 243 条 L2 发现送去人工调查，报告为分析师复核量减少 43 倍。这让监控范围和严重性分流成为可靠性设计的一部分，而不只是告警层。
这项类型错误研究给出了一个针对代理调优工具的可测例子。作者修改了 Shplait，暴露出几种诊断模式，并在 60 个损坏程序、4 种反馈模式和 10 轮运行上做了 2,400 次 qwen2.5-coder:14b 修复试验。更丰富的类型错误诊断改善了修复行为，而修复掉类型错误的修复中有 97.9% 也通过了语义测试。
Mark Brooker 的文章用更直白的话写出了更一般的工程规则：编码代理在能运行编译器错误、测试、基准、形式化规格和模拟器等快速检查时表现更好。这里更强的证据来自 Shplait 实验；那篇文章的价值在于把这个结果连到日常软件工作流。
有两项研究关注代理产出制品之后会发生什么。JetBrains 的代码审查研究把 LLM 生成的多文件改动审查当作一个信任校准问题。它提出的 IDE 工作流依次经过改动总览、按风险排序的文件，以及代码片段检查，里面用了 risk-per-line、risk-per-file、judge、walk-through 和 security cage 等构念。在验证中，63% 的受访者预计总体审查工作量会下降，不过这项研究没有测缺陷发现率或任务耗时。
需求工程研究在产品工作里展示了类似的约束。在 XITASO，产品负责人在 15 个需求用例中使用了 AI，8 名参与者里有 6 名报告了待办项细化。主要的实际限制是工具连接：Jira、Confluence、源代码、招标来源和会议数据决定了 AI 输出是否适合团队流程，或者会不会制造人工交接。