上周 review 一个团队的代码。他们想做一个能自主修 bug 的 Agent，架构设计得很漂亮，模型选的也是最新的。但 Agent 跑起来后，改完代码就停了——它不知道怎么验证自己改得对不对。
我问他们：「测试覆盖率多少？」
「大概 30%，而且跑得慢，本地跑一次要 15 分钟。」
「日志呢？有结构化日志吗？」
「有，但格式不太统一，有时候打 JSON，有时候打纯文本。」
「Health Check 呢？」
「有个 /ping 接口，返回 200。」
我说：那你的 Agent 改完代码之后，怎么知道改对了？怎么知道部署上去没炸？怎么知道要不要回滚？
他想了想：「只能让人看一眼。」
我说：对，这就是问题所在——你的系统不是为 Agent 设计的，是为人设计的。 人可以用经验判断「这个改动应该没问题」，Agent 不行。Agent 只能依赖 可以调用、可以验证、可以反馈 的能力。
一个被忽视的转变
过去几十年，软件工程里一直在讲「可测试性（Testability）」和「可运维性（Operability）」。但说实话，这两个概念在大多数团队里，只是 最佳实践——推荐做，但不做也能跑。
为什么？因为 人可以兜底。
测试覆盖率低？有经验的工程师可以 review 代码，凭直觉判断有没有问题。
日志不标准？出了问题可以 SSH 上去 grep，人肉分析。
没有自动回滚？半夜被叫醒手动回滚，虽然痛苦但能解决。
人可以用经验、直觉、上下文来弥补系统的不足。但 Agent 不能。
Agent 没有经验，没有直觉，没有「看一眼就知道」的能力。 它只能依赖系统暴露给它的接口：能调用测试吗？能解析日志吗？能判断部署成功吗？能触发回滚吗？
这就是今天我要讲的核心观点：
AI 时代，「面向可测试开发」和「面向可运维开发」不再只是工程最佳实践，而是 Agent 能否自主完成工作的前提条件。
为什么可测试变成了前提条件
一个能自主修 bug 的 Agent，工作流是这样的：
收到 bug 报告
↓
分析代码，定位问题
↓
生成修复方案
↓
修改代码
↓
运行测试，验证修复是否正确
↓
如果测试通过 → 提交
如果测试失败 → 重新分析，修改方案
注意第 5 步： 运行测试，验证修复是否正确。如果这一步做不了，Agent 就卡住了——它改完代码不知道对不对，只能交给人看。
但「运行测试」不是简单的一句话。它要求：
| 能力 | 要求 | 为什么 Agent 需要 |
|---|---|---|
| 有完整测试 | 核心路径都有单元测试和集成测试 | Agent 改完代码必须有反馈信号 |
| 能快速运行 | 测试套件 1-2 分钟内跑完 | Agent 的循环是分钟级的，等 15 分钟它会超时 |
| 结果结构化 | 测试输出是 JSON 或标准格式，不是自由文本 | Agent 需要解析结果，判断哪些用例失败、为什么失败 |
| 可定位失败原因 | 测试失败时有清晰的错误信息和堆栈 | Agent 需要根据失败原因调整修复方案 |
如果一个系统的测试覆盖率只有 30%，跑一次要 15 分钟，失败信息是一段模糊的 AssertionError: expected 200 but got 500——Agent 改完代码后，既不知道改对了没有，也不知道错了该怎么修。
这不是 Agent 不够聪明，而是系统没有给 Agent 足够的反馈接口。
我在 图灵完备 Agent 里讲过，Agent 的能力上限不是模型决定的，而是 Runtime 决定的。测试系统就是 Runtime 的核心组成部分——它是 Agent 的 验证能力。没有验证能力，Agent 就不可能自主。
为什么可运维变成了前提条件
同样的逻辑适用于运维。一个能自主部署的 Agent，工作流是这样的：
代码通过测试
↓
触发部署流程
↓
观察部署状态（日志、Metrics、Health Check）
↓
判断部署是否成功
↓
如果成功 → 继续观察业务指标
如果失败 → 触发回滚
这个流程的每一步，都要求系统具备相应的能力：
| 能力 | 要求 | 为什么 Agent 需要 |
|---|---|---|
| 日志标准化 | 结构化日志（JSON），统一格式 | Agent 需要解析日志，判断部署状态 |
| Metrics / Tracing 完整 | 关键指标有埋点，链路可追踪 | Agent 需要判断业务是否正常，问题在哪 |
| Health Check | 不只是 /ping，而是真正的健康检查（数据库连接、依赖服务、业务指标） | Agent 需要判断服务是否 ready |
| 自动发布与回滚 | 一条命令部署，一条命令回滚 | Agent 需要能触发这些操作，而不是手动 SSH |
| Runbook 可机器读取 | 故障处理手册不是 Confluence 文档，而是可执行的脚本或决策树 | Agent 需要知道出问题时该做什么 |
如果一个系统的部署流程是「先 SSH 到服务器，手动拉代码，手动重启服务，然后盯着日志看有没有报错」——Agent 做不了。它需要的是 可调用的接口：deploy()、rollback()、healthcheck()、get_metrics()。
可运维性不是「方便运维人员」，而是「让 Agent 能自主完成运维闭环」。
从「面向人」到「面向 Agent」
过去：
可测试、可运维主要是方便 人。
今天：
可测试、可运维主要是方便 Agent。
这个转变的深层含义是： 这些能力变得更加具象、更加严格。
对人来说，「测试覆盖率 70%」可能就够了——剩下的 30% 可以靠 review 和经验兜底。但对 Agent 来说，那 30% 就是盲区——Agent 不敢动没有测试的代码。
对人来说，「日志格式不太统一」可能只是个小问题——人能看懂就行。但对 Agent 来说，格式不统一就意味着解析失败——Agent 读不懂日志。
对人来说，「部署后看一眼就知道有没有问题」是正常操作。但对 Agent 来说，「看一眼」不是可执行的动作——它需要的是 Metrics、Health Check、结构化日志。
人可以用经验弥补系统的不足，Agent 不能。 所以系统的「可测试性」和「可运维性」必须从「推荐标准」升级到「硬性要求」。
所有 「ability」 都在变成标准化接口
如果把这个思路推广，会发现一个更大的趋势：
AI 正在把软件工程中的所有 「ability」（Testability、Operability、Observability、Debuggability、Deployability）变成一组标准化接口。
过去：
Code → 人测试 → 人部署 → 人观察 → 人修复
现在：
Code → Agent 测试 → Agent 部署 → Agent 观察 → Agent 修复
每一个环节，都需要系统暴露相应的接口：
| 环节 | 需要的接口 |
|---|---|
| 测试 | run_tests() → 返回结构化结果 |
| 部署 | deploy() → 返回部署状态 |
| 观察 | get_metrics()、get_logs() → 返回结构化数据 |
| 修复 | rollback()、restart() → 可触发的操作 |
这些接口不是给人用的 CLI，而是给 Agent 用的 API。它们必须：
- 可调用：Agent 能通过 Tool Calling 触发
- 可验证：Agent 能判断操作是否成功
- 可反馈：Agent 能拿到足够的信息做下一步决策
这就是为什么我说： 好的系统，不是代码写得好不好，而是 Agent 能不能独立完成整个闭环。
Agent Friendly：软件设计的新目标
这个趋势的终点是什么？
软件不只是面向开发者（Developer Friendly），还要面向 Agent（Agent Friendly）。
我在 钉钉开放平台的第一用户不再是开发者，而是开发者的 Agent 里讲过这个观点：当 API 的第一用户从开发者变成 Agent 时，API 设计标准就变了。
同样的逻辑适用于整个软件系统。当系统的第一操作者从人变成 Agent 时，系统设计标准就变了：
| 维度 | Developer Friendly | Agent Friendly |
|---|---|---|
| 文档 | 人类可读的 Markdown | 机器可解析的 OpenAPI / JSON Schema |
| 错误信息 | 人能看懂就行 | 结构化错误码 + 明确原因 + 建议操作 |
| 日志 | 方便 grep 和阅读 | 结构化 JSON，统一字段 |
| 测试 | 覆盖率达标就行 | 快速、结构化、可定位失败原因 |
| 部署 | 有 CI/CD 就行 | 一条命令部署，一条命令回滚，状态可查询 |
| 监控 | 有 Grafana 看板 | Metrics API 可调用，告警可触发 |
Developer Friendly 的系统，人可以高效使用。Agent Friendly 的系统，Agent 可以自主使用。
这两者有交集，但不完全重合。一个系统可以 Developer Friendly 但不 Agent Friendly——文档写得很漂亮，但 Agent 读不懂；测试覆盖率很高，但跑一次要 30 分钟；日志很详细，但格式不统一。
反过来，一个 Agent Friendly 的系统，通常也会 Developer Friendly——因为 Agent 需要的能力（快速测试、结构化日志、自动部署），人也同样需要。
对管理层的启发
如果你要向管理层解释这个趋势，可以这样说：
AI 时代，让「面向可测试开发、面向可运维开发」第一次真正落地——因为这些能力不再服务于经验丰富的工程师，而是直接成为 Agent 自主工作的能力边界。
过去推行测试驱动开发（TDD）、推行 DevOps，最大的阻力是「工程师不愿意改变习惯」。但今天，当 Agent 成为生产力工具时，这些能力不再是「工程师的习惯问题」，而是「Agent 能不能干活的问题」。
一个没有测试的系统，Agent 不敢动。
一个没有结构化日志的系统，Agent 看不懂。
一个没有自动回滚的系统，Agent 不敢部署。
这不是工程纪律的回归，而是工程纪律的强制执行——由 Agent 来执行。
总结
AI 时代，可测试性和可运维性从「最佳实践」变成了「前提条件」。
原因很简单： Agent 不能依赖经验，它只能依赖可以调用、可以验证、可以反馈的能力。 如果你的系统没有这些能力，Agent 就只能在关键步骤停下来等人——而这就不是「自主 Agent」了。
从更大的视角看，AI 正在把软件工程中的所有 「ability」 变成标准化接口。软件设计的目标，也从 Developer Friendly 变成了 Agent Friendly。
这不是一个遥远的愿景。这是一个正在发生的转变——当你决定让 Agent 帮你修 bug、帮你部署、帮你监控时，你就已经在要求系统具备这些能力了。
问题只是：你是主动设计这些能力，还是在 Agent 卡住之后才补？
你的系统，Agent 能独立完成闭环吗？欢迎留言讨论。