平台智能化真正的分水岭，不是 Agent 会不会调工具，而是平台配置能否进入 AI Coding 的工程闭环。
原文链接 ：AI 小老六
很多团队做 平台智能化，第一反应都差不多：先把查询、创建、修改、测试、发布这些接口包成工具，再给大模型接一个 Agent，让它学会替人操作平台。
这条路当然有价值，而且往往起效很快。只要平台本身已经有一套成熟能力，做一个能听懂自然语言、能串流程、能回执结果的 Copilot，并不算特别困难。麻烦出在下一阶段。项目往前推一阵之后，大家通常都会碰到同一个坎：Agent 已经很会调工具了，系统却还是不够稳，也不够"懂"这些配置资产。
原因不在模型笨，也不完全在 prompt 写得不够细，而在于被操作的对象本身就不是为 AI Coding 形态准备的。配置散在页面里、接口里、数据库里，命名方式不统一，依赖关系不显式，历史语义埋在文档和人脑里。Agent 即便把按钮都点对了，也未必真的理解自己改动了什么。
如果从这个角度回看，平台智能化其实正在分成两条建设路线。一条是在既有平台之上补一层 Agent 编排，让 AI 学会调用平台；另一条更往里走，是把 平台配置 一步步改造成 AI 更容易处理的资产，再让 AI 围绕这些资产工作。前者在补操作效率，后者在改平台接口。真正决定上限的，往往是后面这件事。
图：平台智能化的真正变化，不是多接一个 Agent，而是让配置资产进入可读、可改、可评审的工程闭环
工具调用能很快见效，但它解决的是"操作"不是"理解"
先说最常见的做法，也就是 大模型 + Agent + 平台工具调用。
这类方案之所以容易起步，是因为它天然贴着现有平台能力长。查询接口、创建接口、测试能力、状态回传、审批发布，这些本来就已经存在。你要做的，无非是把它们包装成一组可调用工具，再补一个能做任务拆解和流程编排的 Agent。
从平台提效视角看，这很容易打出第一枪。比如 特征创建、规则创建、某类发布操作，只要流程相对清晰、接口已经成型，做成 Agent 驱动的半自动闭环，收益通常都很直观。
但这条路往深处走，问题也会越来越集中。它擅长把一项操作跑通，却不天然擅长把一类资产理解透。因为 Agent 面对的仍然是原来的平台形态：
- 配置入口分散，读一圈成本很高
- 结构和命名不统一，模型很难快速建立稳定心智
- 上下游依赖没有显式收束，影响面分析常常只能临时推断
- 很多关键判断写不进接口，只存在于设计文档、复盘记录和经验里
说白了，Agent 可以帮你把"东西做出来"，但它不一定知道这项配置在整条业务链路里到底扮演什么角色，也不一定知道这次改动最容易踩到哪条边界。
换句话说，工具调用路线做得再成熟，解决的核心仍然是操作智能化。它能让平台更好用，却不必然让平台资产本身变得更适合被 AI 理解。
真正卡住 Agent 的，往往不是能力缺口，而是资产形态太"碎"
很多人把平台智能化的难点理解成"模型还不够强"，这话只说对了一小半。
更常见的情况是，平台里的配置对象天然就不适合被连续推理。人类工程师接手一个系统时，会慢慢在脑子里拼出很多隐含关系：这个字段是谁消费的，这段表达式为什么不能轻动，这个默认值背后对应哪段历史兼容逻辑，这条规则上线前为什么一定要过某个审批口子。
这些关系对人来说可以靠经验补齐，对 Agent 却是实打实的理解成本。如果资产还停留在页面表单和接口回包层面，AI 每次都得重新扫页面、拼文档、猜边界。这样做不仅 token 开销大，结论也容易漂。
所以平台智能化越往后走，重点越不该只是"再给 Agent 补几个工具"，而应该转向另一个问题：
能不能把平台配置本身重组成一个 AI 可以持续阅读、修改、比较和治理的工作区？
这是一个分水岭问题。因为从这里开始，平台智能化不再只是交互层升级，而是资产底座升级。
图：当配置仍然散在页面、接口和数据库里时，Agent 更像在做高成本拼图，而不是稳定地理解资产
配置代码化，关键不是导出 JSON，而是把平台资产变成可治理对象
很多人一听"配置代码化"，第一反应是把页面上的配置导出来，存成 JSON 或 DSL。实际上，这只是最表层的一步。
真正有价值的 配置代码化，至少要同时完成几件事：
- 把线上真实态同步出来，而不是靠手工搬运一份静态副本
- 为核心配置资产提供稳定表达，可以是 DSL，也可以是作者更容易维护的脚本或 canonical 配置
- 把依赖图、索引、反向引用、影响面等辅助信息一起补齐
- 让这些资产进入 Git、diff、MR、review、回滚这些工程流程
- 把长期有效的规则、校验和经验，沉淀成可复用的 Skill、缓存或知识层
做到这一步，Agent 面对的对象就完全变了。
它不再是登录若干页面、依次调用若干接口、从零拼装上下文，而是在一个结构化工作区里处理配置资产。哪些字段属于真源，哪些改动会连到上游，哪些引用会波及别的策略，哪些历史决策是必须保留的，这些信息都可以被显式组织出来。
这件事的价值，不只是让 AI "更好生成"，更重要的是让它开始具备真正的工程可控性。因为一旦配置成为代码化资产，后续的修改、分析、review 和回滚就都可以进入同一套治理链条。
为什么特征创建这类能力，最终会走向"代码转配置"
特征创建就是一个很典型的观察窗口。
如果平台还停留在传统形态，特征创建 大多是一条很直接的链路：
自然语言 -> Agent 理解需求 -> 调平台接口 -> 直接落配置
这条链路能跑，而且短期内确实有效。用户描述一个需求，Agent 去补参数、判类型、组步骤、调接口、回状态，看上去已经很像"智能创建"了。
但只要业务复杂度一上来，大家很快就会发现，这种模式的天花板也很明显。因为它本质上还是 AI 帮人操作平台，重点落在"把配置生出来"，而不是"把配置改成可治理资产"。
一旦平台完成了更深一层的配置代码化，特征创建的实现方式就会跟着变。那时更自然的一条链路会变成：
自然语言 -> AI coding 生成 DSL / canonical 配置 / 脚本 -> review 与校验 -> 代码转配置
别小看这个变化。它看上去只是把生成位置往前挪了一步，实际上是把整个能力接进了 AI Coding 最擅长的主工作流：
- 先生成结构化资产
- 再看 diff
- 再做 review
- 再做依赖分析和影响面评估
- 最后再受控地下发成平台真实配置
一旦变成这条链，平台能力的性质就和以前不一样了。特征创建不再只是"页面配置自动化"，而开始具备版本管理、变更审计、回放复盘和统一治理的条件。
真正值得押注的，不是 Copilot 数量，而是能否接入完整工程闭环
为什么我会更看好"AI Coding Agent + 配置代码化"这条路，说到底不是因为它更时髦，而是因为它更贴近 AI 真正擅长的事。
AI 在工程里真正稳定的价值，从来不是陪你多聊几轮，而是围绕结构化对象完成一整套动作：
- 读已有资产
- 理清结构和边界
- 做受约束修改
- 对比 diff
- 辅助 review
- 结合验证结果继续收敛
这些动作都更适合发生在代码化、索引化、可比较的资产之上，而不是零散页面之上。
更关键的是，只有进入这条链，平台智能化才算真正纳入工程治理体系。那时候讨论的就不再只是"这个 Agent 会不会调接口"，而是更像今天讨论代码工程：
- 变更是否有 branch 和 commit
- 差异是否可审阅
- 依赖影响是否能提前看到
- 错误是否能快速回滚
- 历史决策是否能被追溯
对平台建设来说，这是质变，不是修修补补。因为从这一步开始，AI 参与的已经不是单次操作，而是平台资产本身的长期演进。
两条路线不会互相替代，但底座决定长期上限
这并不意味着工具调用路线没价值，或者应该被放弃。
更现实的建设方式，通常是分层推进：
- 在交互和执行层，继续用
大模型 + Agent + 平台工具调用承接需求理解、任务编排和即时执行 - 在资产和治理层，逐步把关键配置推向
AI coding Agent + 配置代码化
前一层解决入口问题，让平台先具备可用的智能操作能力；后一层解决底座问题，让平台资产本身适合被 AI 持续理解和复用。
如果只做前者，平台会越来越像一个会说话、会点按钮的操作助手；如果把后者也做起来，平台才真正开始拥有面向 AI 的工程接口。
所以两条路不是二选一，而是先后重心不同。只是从中长期看，真正能拉开差距的，往往不是谁先做出一个 Copilot，而是谁先把平台资产组织成 AI 可治理的结构。前者解决的是"先用起来"，后者决定的是"能不能越用越稳"。
总结
AI coding 时代，平台智能化最重要的变化，不是平台外面多包了一层 Agent，而是平台内部的配置资产，开始从"只服务页面和接口"转向"也服务 AI 的理解与修改"。
这也是为什么我会把"配置代码化"看得比"工具接入数量"更重。前者决定 AI 能不能进入真正的工程闭环，后者更多决定它当下能替人省多少点击和搬运动作。
如果必须把判断压成一句话，我更愿意这样说：
让 Agent 学会调用平台，只是平台智能化的起点；让配置资产进入 AI Coding 工作流，才是平台真正长出下一代接口的开始。