Agent 可靠性不能只看"能不能跑通"，要拆三层指标。 任务完成率：标准任务集跑 N 次，统计最终拿到预期结果的比例。最直观但容易掩盖中间过程抖动。 过程稳定性：同样任务跑多次，最终输出虽然一样，但中间几步、调用哪些工具、token 消耗差多少。方差大说明 Agent 在"瞎蒙"。跟踪平均步数、工具调用次数、重试率的标准差。 错误恢复能力：故意注入工具超时、API 报错、网络中断，看 Agent 能不能识别失败、换策略而不是放弃。这一项靠 chaos agent 工具集做故障注入。 实操建一个 Eval 集，分三档：基础、边界、对抗。每周跑一次，结果入看板。别迷信 benchmark，最终要在你自己的业务场景里测。... 展开详请

关键是给每个 Agent 划清权限边界和资源配额。具体做法：工具调用做白名单，写入类操作必须人工确认；每个 Agent session 设 token 上限和超时硬切；文件系统只给工作目录读写权限，沙箱隔离；外部 API 调用走代理，设速率限制和每日配额。上线前做 chaos 测试，故意注入工具超时、API 报错，看 Agent 是优雅降级还是死循环烧钱。监控面板盯三个指标：单次任务 token 消耗 P99、工具调用失败率、异常重试次数。超阈值自动熔断，别等账单炸了才发现问题。Agent 出问题不可怕，可怕的是没有兜底机制。... 展开详请

可以接管一部分，但不能全交。AI 自治适合"模式明确、代价可控"的故障，比如连接池打满、长事务清理、索引缺失建议。 不该让它直接做的：删数据、停服、回滚、跨库事务补偿。这些做错就是事故，AI 决策的可解释性不够，出问题背锅都说不清。 推荐三段式：监控层 AI 识别异常；决策层 AI 给建议（kill 哪个 session、加什么索引）；执行层人工确认或自动执行低风险操作，高风险必须人工 approve。 关键原则：AI 出主意，人/规则拍板。可以让 AI 提议 kill idle session，但实际动作走预定义工具调用，带审计日志、能回滚。 国内几家大厂 AIOps 实践都走这条路。别被 PPT 骗了说 AI 能全自动运维数据库，真出事时没人敢让它拍板。... 展开详请

循环、记忆、工具调度、安全策略这些核心控制流不能插件化，一个坏插件能让 Agent 无限循环或越权。适合插件的是：具体工具（查天气、读文档）、输出格式化、特定领域的反思/评分逻辑、UI 渲染。判断标准：如果插件失败会影响整个 Agent 的可靠性和安全性，就放进核心；如果只是换一种做法，再交给插件。核心要稳，插件要轻。... 展开详请

生产级 Agent 运行时中将 Harness 拆分为“路由层（Router）+ 多策略执行器（Executor）”的目的，是把自由 think-act-observe 循环里容易失控的不确定性（如停止时机、策略切换、降级回退、安全触发、成本与时延）通过路由层前置“控制面”而钉住；路由层根据请求特征与风险信号先决定使用哪种执行器，并下发停止/预算、工具与权限边界、合规安全规则以及输出结构合同，使执行器在固定策略下完成任务并输出可验证结果。若不拆合并在一层，线上最先暴露的往往是控制失效类故障，例如预算或停止条件失控导致成本与延迟爆炸、工具滥用/权限越界、合规与拒答策略不一致引发概率性事故，以及由于缺乏分层决策记录而造成可观测性与可复现性下降；因此当意图不适合自由循环、证据链不足、预算接近阈值、安全风险升高或历史轨迹显示发散时，应由路由层将其降级为确定策略而非继续自由循环。... 展开详请

如果预算只够认真做一层，我会优先补检查点与失败接管这一层。原因是：线上“模型变强但成功率不动”，往往不是推理能力不够，而是失败后无法收敛与恢复（超时、工具副作用、状态丢失导致反复重试）。有了检查点与可恢复状态，Agent 才能在预算耗尽、工具失败、异常注入时降级退出、回滚或续跑；这直接提升稳定性与可用性。权限清单与评测隔离也重要，但它们通常是“优化与治理”，而检查点/失败接管是“生存底座”。... 展开详请