平台智能化真正的分水岭不是 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 工作流才是平台真正长出下一代接口的开始。