AI Agent 写企业软件,为什么也需要一套开发者工具链?

从 ObjectStack 的 Agent Skills、AGENTS.md、MCP 到 Validation，看 AI 编程为什么正在从 Prompt 驱动走向 Skill + Protocol + Runtime

适合阅读：架构师 / CTO / 平台工程 / SaaS 创业者 / AI 应用开发者 / Agent 工程师

当你打开 Claude Code 或 Gemini CLI,对它说:帮我创建一个 CRM 的 Opportunity(机会)对象,加上金额字段、销售阶段,再加一个『批准』的 Action,最后生成一个对应的列表视图。

一个足够强的模型,可能很快就写出了一堆东西。但真正的问题,恰恰在这之后冒出来:

注意:这些问题,没有一个是模型会不会写代码的问题。模型很会写。这些问题问的是另一件事——模型有没有一个好的开发环境,让它知道在这个具体的项目里,该怎么正确地工作。

Agent 开发软件的核心矛盾,正在从代码生成,转向开发环境。会写代码,只是入场券;能在一个特定的软件体系里正确地写,才是真本事。

如果 AI Agent 开始像开发者一样构建软件,那软件是不是也该为它,准备一套专门的开发者体验?

一、一个通用 Coding Agent，不一定真的懂你的企业软件

先说明 Claude Code、Cursor、Gemini、Copilot 它们的通用编程能力,非常强,这一点毫无疑问。

但通用编程能力强和懂你的企业软件该怎么定义,是两码事。通用模型理解的是怎么写 TypeScript、Python、React,它不一定理解你的企业软件,应该如何定义一个业务对象。

举个例子。写一个普通的 TypeScript 类:

这在通用编程里,完全合法。但在一个特定的企业软件体系里(比如 ObjectStack),一个Customer可能需要遵循某种特定的元数据 Schema,可能还需要有字段、关系、标签、权限、视图、动作、校验——一整套东西。通用模型未必知道这些约定。

会编程和会在一个特定软件体系里正确编程，是两回事。

那人类开发者是怎么解决这个问题的?靠一整套环境:README、架构文档、编码规范、IDE、CLI、类型系统、框架、测试、文档。一个新人进项目,正是靠这些东西,才慢慢学会在这个项目里该怎么写。

AI Agent 也一样。你不能指望它天生就懂你的项目——它也需要一套类似的环境,告诉它这个项目的规矩、工具和边界。

二、AGENTS.md：给 Agent 的项目说明书

从这里,我们开始看 ObjectStack 仓库里那些真实存在的东西。第一个,是 AGENTS.md。

传统项目里,写给开发者的文档是这些:README、架构文档、编码规范。它们的读者,默认是人类开发者。

而现在,项目里可能开始需要多一份东西:

根据当前仓库,AGENTS.md 大致扮演的角色,是给 Agent 的项目上下文 / 指令层——它告诉 Agent:在这个项目里,应该遵守什么规则、项目结构是怎样的、有哪些命令、什么该做什么不该做。它相当于给 AI 开发者的一份入职说明。

一个判断:未来的软件项目,可能不只需要给人看的开发文档,还需要给 Agent 看的开发规范。README 面向人,AGENTS.md 面向 AI。

但这里必须泼一盆冷水,别把 AGENTS.md 神化。它本质上只是一个上下文 / 指令层——它能告诉 Agent应该怎么做,但它是自然语言的、软性的。它替代不了 Schema、类型系统、校验器、运行时治理这些硬约束。一句写在 AGENTS.md 里的请不要修改权限文件,和一道运行时真正拦住越权的关卡,完全是两回事。

三、Prompt，为什么不是长期可靠的工程方式？

我们先看看纯 Prompt这种方式的问题。

你对 Agent 说一句请帮我创建一个 CRM。这句 Prompt,作为一次性的指令没问题,但作为一种工程方式,它有一堆毛病:

如果把这种一次性口头指令,换成一套结构化的能力呢:

Agent 得到的,就不再是一句可能被理解偏的话,而是一套结构化的、可复用的能力。

Prompt 是一次性指令；Skill 更像可复用的专业知识 + 操作流程。

四、Agent Skills，到底是什么？

先破一个误解:别把 Skill 简单理解成一篇 Markdown 文档。它比那要重。一个 Skill,可以包含一整套东西:

所以更准确的理解是:Skill 更像 Agent 的一个专业技能包,而不是一次性的 Prompt。它把完成某一类特定任务需要的知识、流程、工具、规范,打包在一起,让 Agent 可以反复调用。

打个类比,人和 AI 各自靠什么学会在一个框架里干活:

五、Skill + Schema，为什么比 Prompt + Code 更可靠？

我们对比一下两种模式。

模式 A：Prompt + Code

模式 B：Skill + Schema + Runtime

两种模式的核心差别,在于每一层对 Agent 说的话不一样:

看出这个递进了吗?从你可以试试,到你只能这样,到你的结果必须合规。约束一层层收紧,Agent 的自由被框定在一个安全、合法的空间里。于是——Agent 的能力,不再只由模型本身决定,而是由模型 + 环境共同决定。

同一个模型,放进一个有 Skill、Schema、Validation、Runtime 的环境里,和扔进一个只有 Prompt 的空白环境里,产出的可靠性,天差地别。环境,是模型能力的放大器,也是它的安全带。

六、为什么 MCP 只是工具层，而不是完整的 Agent DX？

很多人有个误解:以为接上了 MCP,Agent 就万事俱备了。但 MCP 只是其中一层。把各层的职责摆清楚:

看清楚层级,一个判断就清楚了:MCP 解决的是工具连接——它让 Agent 能调用系统的能力。而 Agent DX 解决的,是「Agent 如何在整个软件环境里工作」。前者是一层,后者是整个体系。

只有 MCP,没有 Skill、Schema、Validation、Runtime,Agent 只是有了更多工具,并没有真正拥有一个开发环境。工具多,不等于会干活。

七、AI 也需要一套类型系统

人类开发者靠类型系统+ IDE,在写代码时就得到即时的约束和提示。Agent 也需要一个对应的东西——面向元数据的类型化 Schema + 校验。根据当前仓库,ObjectStack 在这一层用到了 TypeScript、Zod、Schema、JSON Schema、元数据校验等。

但这里有个更深的观点,值得展开:类型系统对 Agent 来说,不只是约束,它更是一种机器可理解的设计空间。

它清清楚楚地告诉 Agent:什么可以存在、什么不能存在、什么类型是合法的、哪些字段是必须的、哪些关系是允许的。这等于给 Agent 画出了一张合法地图。

于是,Agent 不再是在一个无限的可能性空间里瞎生成,而是在 Schema 定义的合法空间里做搜索。搜索空间从无穷,收敛成有限且合法——这对 AI 生成的可靠性,是决定性的。

这是一个很值得琢磨的 AI 工程观点:约束,不是在限制 AI,而是在帮 AI。 一个划定了边界的空间,比一片无边无际的旷野,更容易让 AI 找到正确答案。

八、AI Coding 的真正闭环，不是 Generate，而是 Feedback

今天很多人对 AI Coding 的想象,还停留在一个过于简单的三步:

但真正可靠的 Agent 开发体验,应该是一条完整的闭环:

这条闭环里,生成只是其中一小步。真正决定质量的,是后面那些——校验、预览、观察、修正。一个成熟的开发者,大部分时间不是在写,而是在验证和修正。Agent 也该如此。

AI Coding 1.0 是生成代码;而真正的 AI-Native 开发,是在一个环境里,理解、修改、校验、预览、修正、再部署。前者是一次性输出,后者是一条工程闭环。

九、Preview，为什么可能比生成代码更重要？

在上面那条闭环里,有一步特别值得单拎出来讲:Preview。

一个 Agent 改完东西,它不应该只得到一句冷冰冰的命令执行成功。它应该得到的是——你刚改的这个应用,现在长什么样。

这其实和人类用 IDE 的过程一模一样:写代码 → 编译 → 运行 → 看结果 → 再改。人类程序员极度依赖看到运行结果这个反馈——没有它,你是在盲写。

所以,AI Agent 的视觉 / 运行反馈,很可能是 Agent DX 里的一等公民。让 Agent看见它改出来的东西,和让它「以为」自己改对了,是两个完全不同的可靠性级别。

十、为什么Examples本身，也是 Agent 的学习材料？

根据当前仓库,ObjectStack 有一批 examples(如 Todo、CRM、Showcase、ObjectQL 嵌入等,)。

这些 examples,对人和对 AI,意义不太一样:

差别在于:Agent 不只是在读Object 应该怎么写这种抽象说明,它还能直接观察这个真实的仓库,实际上是怎么写 Object 的。真实的、能跑的例子,比抽象的文档,更能让 Agent 学到这个项目真正的写法。

所以一个观察:示例仓库,可能正在从文档的附件,变成 Agent 可利用的结构化参考样本。

但这里要谨慎,别把话说过头:examples 不等于训练数据。更准确地说,它是 Agent 在上下文 / 工具辅助开发的过程中,可以利用的参考样本。它帮 Agent 现场理解这个项目,而不是去训练模型本身。

十一、Claude Code、Gemini CLI 等集成，真正说明了什么？

我不评测这些工具谁强谁弱,而是问一个更本质的问题:一个企业软件项目,为什么要专门去做这些 Agent 集成?

如果一个仓库,同时提供了对 Claude Code、Gemini CLI 等的集成,它说明的其实是一件事:

企业软件，开始需要向 Agent 提供自己的开发者接口了。

对比一下这个变化。过去,一个库的使用者是开发者:

而现在,一个业务 Runtime,开始面向AI 开发者提供接口:

这里的核心,不是ObjectStack 支持了哪些 AI 工具这种功能点,而是一个更深的判断:业务 Runtime,开始拥有一种新的使用者——AI 开发者。而这个Agent 开发者接口,可能是由 AGENTS.md、Skills、MCP、CLI、Schema、Examples 共同组成的。

十二、Agent DX：一种新的开发者体验

到这里,可以正式提出本文的概念模型了。

我们太熟悉开发者体验(DevEx)这个词了。对人类开发者,它意味着一整套东西:

而如果开发者里开始有了 AI,那对应地,可能需要一套面向 AI 的开发者体验——我把它叫做 Agent DX:

必须说清楚:Agent DX 不是给 Claude 写几个 Prompt那么简单。它是——围绕AI 开发者的一整套完整软件工程环境。就像 IDE + 编译器 + 测试 + 文档共同构成了人的开发环境一样,Context + Skills + Schema + Tools + Validation + Preview + Runtime 共同构成了 Agent 的开发环境。

(再次说明:Agent DX只是我为了讨论这个问题提出的分析概念)

十三、未来的AI IDE，可能不只是 IDE

传统 IDE 的核心,是帮人编辑代码——文件树、编辑器、标签页、自动补全。但一个面向 Agent 的开发环境,它的核心可能完全不同。因为 Agent 不太需要编辑器那一套。

它真正需要的,可能是这些:

你会发现,这份清单里,几乎没有编辑器的影子。于是一个判断浮现:AI Coding 产品,最终可能从代码编辑器,逐渐走向软件控制台——它管理的不是文件和光标,而是理解、修改、校验、运行、审批这一整套软件的生命周期。

十四、Agent DX 的基本单位，可能不是文件，而是任务

传统 IDE 的工作单位,是文件——你一个文件一个文件地打开、编辑、保存。但 Agent 的工作方式不是这样。它面对的是一个任务,而这个任务,往往横跨很多文件、很多工具、甚至整个 Runtime。

比如一个任务:创建一个 工单系统。」Agent 为了完成它,可能需要同时:

所以,Agent DX 的基本单位,可能不是文件,而是任务 / 变更集 / 业务能力。Agent 关心的是把这个业务能力完整地做出来,而不是编辑好这一个文件。

十五、这会让软件项目的代码仓库发生变化吗？

这是一个有意思的问题。

传统项目的核心资产,是这些:

而一个 AI-Native 的项目,它的核心资产,可能会越来越多地包括这些:

这不是说传统的 src/、tests/ 会消失。而是说:对于 AI-Native 项目,那些给 Agent 使用的知识与约束层(元数据、技能、规范、策略、示例),会成为和源代码同等重要的一等项目资产。仓库里,不再只有『给机器执行的代码』,还有『给 AI 理解的知识』。

十六、Agent DX 最难的，其实不是工具，而是边界

Skill 很方便、MCP 很强、CLI 很强。但有一条铁律:

给 Agent 的工具越多、能力越强，风险也就越高。

所以,一个好的 Agent DX,绝不能只顾着给 Agent 更多能力,它必须同时,把能力关进治理的笼子里:

优秀的 Agent DX,不是让 Agent 获得最多的能力,而是让 Agent 在清晰的边界内,获得足够的能力。能力要给够,但边界必须清楚。

十七、ObjectStack，为什么值得从 Agent DX 角度研究

最后回到 ObjectStack，根据当前仓库,它把这些东西放在了一起:

这些东西,单独拎出来看,都不新——文档、技能包、类型 Schema、命令行、工具协议、校验、运行时、示例,每一样都是老概念。但当它们被有意识地组合在一起、共同服务于Agent 如何在这个项目里开发时,一件新的事情就发生了:它们开始形成一个面向 AI 开发者的完整开发环境。

这才是 ObjectStack 当前最值得观察的地方:不是它有某个单点功能,而是它把这一整套东西,拼成了一个 Agent 能在里面完整工作的环境。整体,大于部分之和。

十八、那这套方法，还存在哪些问题？

1　上下文维护成本

Skills、AGENTS.md 越写越多,Agent 要背的上下文就越来越复杂、越来越重。多,不总是好事。

2　Skill 漂移

代码变了,但 Skill 没跟着更新。结果 Agent 照着过时的 Skill,学到了错误的方法。文档和现实脱节,在 AI 时代危害更大。

3　工具爆炸

MCP 工具太多,Agent 在该用哪个工具上的选择成本就飙升,反而容易选错。

4　示例漂移

Examples 和真实架构不一致时,Agent 可能忠实地复制了一个过时的、甚至错误的模式。

5　Agent 评估

怎么判断 Agent做对了?这件事很难。不能只看代码能不能跑,还得看:它符不符合业务模型、遵不遵守规范、用没用对工具、有没有越权、有没有产生副作用。这套评估体系,本身就是个大难题。

十九、未来的软件工程，可能出现Agent CI

这里提一个未来方向。

传统的 CI,是围绕代码的:构建 → 测试 → Lint → 部署。而如果 Agent 成了软件的构建者,可能会出现一种新的 CI——围绕Agent 的变更来做:

这套Agent CI可能会自动判断一些新问题:Agent 有没有真正完成任务、有没有顺手改了不相关的东西、有没有违反 Skill 的规范、有没有偷偷改动权限、有没有引入新的安全风险。

结语：AI 编程的下一步，不是更会写代码

回到标题。用一条演进,收束全文:

AI Agent 未来真正需要的,不只是一个更强的模型。它需要的,是一整套环境:上下文、技能、协议、结构、工具、校验、预览、运行时、治理。

AI 编程的下一阶段，不是AI 终于学会写代码， 而是软件，开始为 AI 设计开发环境。

落到 ObjectStack:它值得观察的地方,不只是它让 Agent 写 Metadata,而是——它正在把 Agent Skills、项目规则、Schema、MCP、Validation、Runtime 和 Examples 组合起来,为 AI 开发者提供一条新的开发路径。它未必是最终答案,但它是一个值得研究的、具体的开源案例。

过去,我们在给程序员做 DevEx;而现在,我们可能正在开始,给 AI 做 Agent DX。过去我们设计软件,是为了让人更容易开发和使用它;下一阶段,我们可能还要设计软件,让 AI 更容易理解、修改、验证和运行它。

——本文以 ObjectStack 开源项目为案例进行技术分析。涉及仓库能力(AGENTS.md / Skills / MCP / CLI / Validation / Runtime / Examples / Agent 集成)的部分,以其当前公开源码和文档为准。

ObjectStack · 开源的 AI-Native 企业软件运行时