惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
Docker
人人都是产品经理
人人都是产品经理
小众软件
小众软件
博客园 - Franky
WordPress大学
WordPress大学
Jina AI
Jina AI
Google DeepMind News
Google DeepMind News
I
InfoQ
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
F
Fortinet All Blogs
博客园 - 【当耐特】
IT之家
IT之家
G
Google Developers Blog
J
Java Code Geeks
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
云风的 BLOG
云风的 BLOG
Recent Announcements
Recent Announcements
有赞技术团队
有赞技术团队
V
Visual Studio Blog
U
Unit 42
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
GbyAI
GbyAI
雷峰网
雷峰网

博客园 - 咸着的鱼25

OpenCode + OpenSpec + Oh-My-OpenCode 联合 SDD/ATDD 开发指南 AI 驱动开发工作流:OpenCode + Oh-My-OpenCode + SDD + ATDD 在线服务数据压缩算法比较 延迟深度链接 搭建wiki系统后端存储-来自大模型 广告投放名词 java spring IoC原理 面试题1 c++ 代码技巧 c++ 性能分析 粗排治理之性能优化 MMR 算法优化 core 基本操作 聊天室开发心得 Docker 学习笔记 Airflow 使用简介 lua转换etcd应答 修改系统参数 https学习笔记 openresty: nginx worker不同请求之间共享数据
环境才是 Agent 的核心基础设施
咸着的鱼25 · 2026-08-03 · via 博客园 - 咸着的鱼25

环境才是 Agent 的核心基础设施

内网看到别人发的文章,感觉很有道理,整理了下,转到这儿来

用一个可以随身携带的问题衡量所有 AI 投入:下一代 SOTA 模型发布时,我正在做的这件事,是获益,还是作废?

一、两条路线

目前的主流做法,是把 AI 嵌进一套人类设计的固定流程:PRD → 需求澄清 → 技术方案 → 任务拆解 → 生码 → 测试。每个节点调用 AI 做局部提效,节点之间的验收和流转仍按老流程走。SDD、各种 Agent Skills、Superpowers 这类插件,本质上都是同一条路线。

这条路线有一个结构性天花板:它优化的是"人使用 AI 的方式",而不是"AI 使用环境的方式"。

图1-两条路线.drawio

二、workflow 路线的天花板

每个节点都等人验收、按人画的管道流转,AI 实际上被困在条条框框里。

这套分工方式是人类协作时代的产物,把它固化成 Agent 必须遵守的执行顺序,本质上是在 AI 时代重新引入瀑布模型——它假设需求澄清后就是对的、方案评审后就是可行的、实现阶段只需忠实执行。

但真实的开发不是这样:一次测试失败,可能来自实现、环境、数据、架构假设或需求理解中的任何一层。任何失败都回退到方案重新生码,只会把已经做对的判断一起推倒。而且,按 Jack Reeves"代码即设计"的逻辑,技术方案并不等价于代码——设计要到代码运行起来才算完成。

需要说清楚的是:反对的不是验收本身。合规、问责、高风险决策当然需要人工卡点。反对的是在每一跳都设人工验收,让 AI 在每一步都等人踩油门。

三、agentic:让 AI 自主获取验证信号

另一条路线是 agentic。它的本质不是"AI 主导决策",而是——AI 能否自主获取验证信号,不用每一步都等人来判断对不对。

在这条路线里,workflow 并不消失,它退到自己该待的位置:调度、权限控制、状态保存、审计和高风险检查

电气化的历史是一个恰当的类比。工厂电气化真正的跃升,不是把蒸汽机换成发电机,而是单元驱动——让每个工位摆脱中央传动轴,获得独立运转的能力。旧范式里,所有工位的动力来自同一根中央轴(人的流程);我们要做的,是让 coding 这个工位先独立转起来。

四、一笔投资账:SOTA 问题

两条路线怎么选,落到日常就是一笔投资账。所有 AI 相关的投入,都可以用这一个问题来衡量:

下一代 SOTA 模型发布时,我正在做的这件事,是获益,还是作废?

按这个标准,投入分成两类:

贬值区:围绕"生成能力"的投入。 微调模型提升生码质量、囤积提示词技巧、精细编排生码流程。过去一年反复上演的剧情是:昨天的脚手架,变成今天模型的内置能力。在这条线上投入,等于和模型厂商的军备竞赛对赌。

增值区:围绕"环境与验证"的投入。 把企业内部的构建、部署、测试、数据、接口、日志、监控、发布链路,做成 AI 可调用的工具。这件事没有任何厂商能替我们做;而且模型越强,这些资产越值钱——同样的环境,更强的模型能跑出更深、更长的自主循环。

贬值和增值的分界线,不在"编排"还是"环境"这两个词上,而在它和模型能力的关系上:

  • 凡是替代或补偿模型推理能力的东西——拆解步骤、设计提示词、编排流程——都会被模型的下一次升级吸收,因为模型厂商恰恰是在这些维度上训练下一代模型;
  • 凡是给模型提供它自己造不出来的信息的东西——内部系统的真实状态、构建结果、日志、测试反馈——都会持续增值,因为关于世界的信息只能从世界里来,不可能从权重里长出来

图2-贬值区与增值区.drawio

五、乘法关系:红利 = 模型能力 × 环境能力

为什么环境会持续增值,而生成投入不会?可以用一个简单的关系来理解:

企业从 AI 拿到的红利 ≈ 模型能力 × 环境能力,是乘积,不是加和。

模型是这个乘积里租来的因子,跟着厂商的节奏自己往上涨;环境是自有的因子,只能靠我们自己建,而且只涨不跌。乘法的意思有两层:

  • 任何一端是零,结果就是零——再强的模型,进不了我们的环境,生产力就是零;
  • 模型每变强一代,都会把同一套环境的价值重新放大一遍

workflow 化的收益是线性的,因为它只是给现有环节加了个常数;环境投入的收益是复利的,因为它在乘法里占住了一个因子。

需要补一句防御:环境中不折旧的是信息本身——内部系统状态、构建结果、日志、测试反馈;可能被换代的是接口层——工具的具体调用形态和协议。所以正确的姿势是把世界信息沉淀下来,让接口适配保持廉价,不在接口形态上过度雕花。

所以主张是:不做"如何让 AI 生码更强"的军备竞赛,只做企业内部环境的工具化。 这不是说模型相关工作一概不碰——模型选型、评测、上下文接入当然要做——划界标准就是上面那个 SOTA 问题。

六、环境建设的五件事

具体到建设清单:

1. 业务领域知识的构建。 业务域 SKILL、本体知识库等。这是模型权重里长不出来、又直接决定判断质量的信息。

2. 可复现、可调用的研发环境。 让 Agent 能独立构建项目、启动服务、准备数据、调用接口、操作浏览器或 APP(手淘、千牛)、查看日志和调用链、读取监控指标。本质是把"只有人会操作的内部系统",翻译成"AI 可调用的工具"。

3. 分层验证体系。 这是五件事里最难、也最先起效的一件,建议从秒级反馈做起,因为它直接决定自主迭代的速度,是复利公式里最先转动的因子。

图3-分层验证体系.drawio

  • 秒级反馈:编译、类型检查、单元测试——适合高频自主迭代,Agent 可以不打扰任何人自己跑;
  • 分钟级反馈:集成测试、契约测试、浏览器自动化——覆盖更真实的行为;
  • 人工判断:只保留给机器无法可靠裁决的部分——业务价值、用户体验、伦理边界。

4. 端到端的研发系统打通。 研发流程涉及一系列系统——O2、ZCache、MTL、一休、A+、Orange、Aone、Switch 等——需要将它们改造为 AI Friendly 的模式。

5. spec 与技术方案的新写法:区分"约束"与"假设"。 数据不能出域、接口必须向后兼容、延迟不能超过阈值——这些是约束,要长期保存并尽可能自动检查;微服务还是单体、用哪种缓存策略——这些是有待验证的假设,应允许 AI 根据实现和运行中的反馈自己调整。spec 负责划定"什么算对"的边界,不负责规定实现路径。

需要回答的一个遗留问题是:谁来判断某一条是约束还是假设?这本身是人工判断,也是最容易扯皮的地方。一个可操作的默认规则:有争议时先按约束处理——错把约束当假设的代价(出域、破坏兼容、超阈值),远高于错把假设当约束的代价(少一点自由度)。

七、结语

模型能力是租来的,环境是唯一自有的。workflow 化赚的是常数,环境建设赚的是乘法里的因子。把企业内部的构建、测试、部署、数据、监控翻译成 AI 可调用的语言——这件事没有厂商能替我们做,而模型每强一代,都会把它的价值重新放大一遍。