这是 2026 年的第 20 篇文章
本文阅读时间：约 30 分钟
（本文作者晓斌，阿里巴巴研发基础设施负责人）
前言：从一个周报系统说起
过去几个月，我构建了一个小型系统：通过 connector 打通代码托管、项目管理、数据平台及 IM 等多个异构系统，聚合活动数据并生成周报，最终发布至内部 Pages 站点。该系统的架构可概括为：connector 连接异构系统 → 规范化为统一活动流 → 意图（skill）驱动聚合与排版 → 生成单文件 HTML → 推送部署。
系统由三类核心组件构成：
- Agent：核心驱动力。读取自然语言描述的意图文件（
SKILL.md），动态生成 Python 脚本处理数据及 HTML 进行渲染。 - 代码：大部分为 Agent 运行时按需生成的短生命周期脚本，执行后即丢弃。
- Infra：包括内部 Pages 托管、CI 部署及 Git 版本控制。对开发者而言，这些设施趋于“不可见”，Agent 自动完成推送与触发部署。
该系统的显著特征在于其意图是动态的。SKILL.md仅用自然语言描述需求，在单次迭代中可多次调整（如增加模块、调整顺序）。每次修改后，Agent 立即重新生成代码并部署，将迭代循环压缩至分钟级。
由此观察到两个关键现象：
- 代码即生即弃（Generated on the fly）：代码生命周期从“月/年”缩短至“分钟”。如同 JIT 编译生成的机器码，这里的脚本是中间产物而非资产。
- Infra 透明化：Git、CI 等退居后台，开发者仅需表达意图并验收结果，构建与部署过程完全透明。
这一案例引发了一个深层思考：当越来越多的系统以此模式运行，当前围绕“人写持久化代码”设计的 Developer Infra 是否仍能胜任？
01 本质观察：软件是“意图驱动 + 代码沉淀”的进化体
无论是传统研发还是 Agent 研发，软件系统始终遵循“意图（不确定性）驱动 + 代码（确定性）沉淀”的进化模式。变化的仅是驱动与沉淀的速度及机制。
传统研发中的模式
在传统循环中：用户意图 → 产品经理压缩意图 → 研发翻译为代码 → 上线运行 → 新意图涌入。人是意图到代码的桥梁，受限于认知带宽，循环周期通常为周或月级别。
Agent 研发中的模式
引入 Agent 后，循环变为：意图（自然语言/SKILL.md）→ Agent 理解并生成代码 → 执行反馈 → 意图修正。桥梁从“人”变为"Agent"，循环速度压缩至分钟级。
对比两个案例可见模式的一致性：
- 镜像仓库建站（Agent 占比约 50%）：涉及跨平台配置的结构化 SOP。Agent 执行技术操作，人负责风控环节（如生产环境推送）。循环周期从 2 人日压缩至 1.5 小时，人机边界由出错代价决定。
- 周报系统（Agent 占比约 90%）：桥梁几乎全由 Agent 承担。人仅负责表达意图和验收。Connector 不仅连接 API，更隐含了工作规范，要求团队“按规范沉淀”而非单纯“按流程执行”。
两者的差异不在模式，而在速度。由此得出三个推论：
- 推论一：Agent 是加速而非革命。它未改变软件进化结构，只是将“意图→代码”的循环速度提升了数个数量级。
- 推论二：静态沉淀不会消失。不确定性消除后，确定逻辑应固化为代码。Agent 占比随时间呈锯齿形波动：新意图涌入时陡升（探索期），逻辑固化时缓降（沉淀期）。锯齿形态本身即是系统健康度的诊断工具。
- 推论三：基础设施面临重构。当循环速度从月级跃升至分钟级，原有基于慢循环假设（如离散构建、人工审批、稳定测试环境）的基础设施将成为瓶颈。
02 统一框架下的三个变量
Agent 改变了“意图驱动 + 代码沉淀”框架中三个关键变量的取值：
桥梁带宽：从人到 Agent
“意图→代码”的桥梁切换为 Agent，带宽提升数个数量级。人后退为意图表达者与结果验收者。在镜像建仓案例中，Agent 凭借无上下文丢失、不漏步骤的优势，实现了“新手+AI=老手产出”的效果，SOP 从“面向人的菜谱”转变为“面向 Agent 的可执行意图”。
沉淀粒度：持久代码与瞬态代码的分化
代码分化为两种形态：
- 瞬态代码：On the fly 生成的一次性中间产物，生命周期分钟级，用完即弃（如周报系统的数据处理脚本）。
- 沉淀代码：经反复验证后固化的逻辑，需版本控制与测试（如 connectors.yaml、CI 配置）。
越是动态的系统，越需要坚固的静态约束（类型系统、沙箱、权限边界）作为护栏。
循环频率：从发布周期到运行时反馈
迭代性质从离线、批量、有审批流的离散事件，转变为在线、增量、实时反馈的连续过程。“发布”概念变得模糊，系统在意图与反馈驱动下持续演化。三个变量的乘法效应导致原有 Infra 系统性失配。
03 把动态性推到极致
传统软件假设“意图可枚举”，而 Agent 将承担部分产品经理职能，在运行时直接理解用户意图并生成执行路径。面对开放意图空间，Agent 占比存在不可压缩的下界。这一变化将沿着“意图驱动”逻辑，深刻影响产品形态与组织分工。
04 从三个案例看 Agent 与 Infra 的摩擦
以下三个案例揭示了现有 Infra 在适配 Agent 时的痛点：
案例一：多角色 Agent 研发系统
基于内部研发 CLI 搭建的多角色 Agent 系统（Discovery、Delivery、Examiner 等）覆盖了完整研发链路。尽管 CLI 已具备一定 Agent 友好性，但实际运行中痛点密集：
- 运行环境手工搭建：缺乏根据角色、任务自动组装的完整工作环境（Harness）。
- 规范缺乏机器可读承载：研发标准散落在文档与经验中，Agent 只能临场猜测。
- 接口残留“人用”痕迹：缺乏强类型区分，隐性规则未显式化，状态机边界模糊。
- 验证难度梯度大：从 CLI 到 Web 端验证难度剧增，缺乏自动化手段。
- Code Review 缺上下文：Review 者难以获取需求背景与设计意图，只能关注表面问题。
- 缺乏可重复实验场：缺乏可控的 Dry-run 环境与 Mock 机制。
案例二：配置推送——自主程度取决于安全护栏
在镜像建仓案例中，阻碍 Agent 自主推送配置的并非能力不足，而是 Infra 侧缺乏资源归属治理、Dry-run 能力及分级回滚机制。一旦提供严格的权限管控与变更预览（Dry-run），人员即可放心授权。
Agent 能否自主操作，不取决于 Agent 有多聪明，而取决于 Infra 提供了多强的安全护栏。
案例三：身份与鉴权的碎片化
Agent 需跨越多个系统（Git、CLI、中间件、监控），面临多套身份体系并存的问题。人的角色分工曾屏蔽了这种复杂度，但 Agent 打破了边界，导致身份切换频率呈指数级放大。理想状态是 Agent 拥有一个在所有 Infra 上通用的统一身份。
共性根源
上述问题的根源在于：现有 Infra 均为面向人（People-Oriented）设计，依赖人的常识、责任心与低频操作来弥补机制缺失。而 Agent 无常识、高频操作且需自动恢复，必须依赖面向 Agent（Agent-Oriented）的机制化保证。
05 设计原则：从 People-Oriented 到 Agent-Oriented
面向 Agent 的 Infra 设计，本质是将隐式依赖人的认知与责任心，显式化为系统机制。Infra 需在四个层次提供能力，以扩大 Agent 的安全自主空间：
- 可理解（Comprehensible）：系统概念体系自洽完整，不依赖隐性知识。运行环境需自描述（Manifest/Devcontainer），确保 Agent 能建立正确心智模型。
- 可操作（Operable）：支持 Dry-run、幂等重试、原子组合操作及隔离执行。凭证不应进入沙箱，而是通过 Vault 或代理注入。建立渐进信任机制，低风险操作自主执行，高风险操作需人工确认。
- 可感知（Observable）：状态与结果需结构化、实时且语义丰富。避免沉默失败，每次响应需提供足够信息供 Agent 决策下一步行动。
- 可追溯（Traceable）：支持状态恢复、过程回放与行为审计。Agent 的失败模式是 Infra 设计缺陷的放大器，可通过其行为数据度量 Infra 质量。
06 行业趋势与我们可以做什么
行业实践印证了上述判断：
- 并行 Agent 需要并行 Infra：Superset 等案例表明，环境初始化速度直接决定并行效率，Infra 吞吐量需随 Agent 数量线性扩展。
- Human DX 与 Agent DX 正交：Google Workspace CLI 等实践强调，Agent 首要优化的是可预测性（Predictability）而非可发现性。需通过 Schema 自省、输入加固及响应消毒来防止 Hallucination。
- Credential Brokering 成为共识：多家厂商趋向于引入凭证代理层，Agent 仅携带占位符，由代理层替换真实凭证，实现“使用但不持有”。
行动建议
- Harness 平台化：将 Agent 运行环境内建为平台能力，支持声明式定义与即时供给。
- 统一身份体系：构建 Agent-native 身份，实现全 Infra 通用、自动轮转及最小权限，远期迈向 Credential Brokering。
- Dry-run 基础设施化：在 Infra 层提供统一的变更预览能力，标准化输出 Diff、影响范围及风险等级，作为渐进信任的基础。
- 验证体系演进：融合传统测试与 Agent 评测，从精确匹配转向约束满足，建立持续验证机制。验证基础设施的投资优先级应高于生成能力。
- Agent 行为驱动的度量：利用 Agent 的重试频率、错误类型等行为数据，量化并改进 Infra 的 Agent 友好度。
未来的 Git、CI/CD 系统将收缩至“持久化代码”领域，而支撑"Agent+Code"动态混合体的新一代基础设施将成为建设重点。Infra 的能力边界，即为 Agent 的自主边界。
致谢：感谢残风、星楚、晚馡提供的实践案例和深入讨论，感谢飞桨分享的沙盒环境 Agent 鉴权实践。
参考资料
Vercel Blog, "How Superset built the IDE for AI agents on Vercel", 2026-05-10.
[2] Justin Poehnelt, "You Need to Rewrite Your CLI for AI Agents", 2026-03-04.
[3] Tony Dang, "Credential Brokering for AI Agents", Infisical Blog, 2026-05-23.
脚注
- 文中"研发 CLI"指公司内部覆盖代码仓库、MR、CR、发布流水线等研发全流程的命令行工具。"统一鉴权框架"指公司内部统一多个 CLI 身份体系的鉴权框架。两者均为内部系统，名称已做脱敏处理。
- 飞桨，《沙盒环境 Agent 7×24 小时工作，免登鉴权怎么破？》，内部技术社区，2026-05-26。
*封面头图来自 MoMa，侵删。