AI应用工程：从模型能力到企业生产力：AI 应用为什么正在进入工程化时代？

近期，团队在讨论 AI Coding 时，经常会遇到这样问题：

给模型一句 Prompt：

 复制代码你是一名前端开发工程师。
请帮我生成一个 React 列表页面。

模型很快可以给出 JSX、样式、分页逻辑，甚至一套看起来还不错的 TypeScript 类型。可如果把任务换成：

 复制代码在现有项目中新增一个违规处置列表页面，并满足业务规则、权限要求和团队工程规范。

验收对象就不再是“有没有生成一段代码”，而是：

• 需求有没有理解对；
• 已有组件有没有复用；
• 接口字段和权限规则有没有接错；
• 修改是否符合仓库规范；
• lint、测试和构建能不能通过；
• 失败之后能不能定位并修正。

模型已经会写代码，为什么任务还是不能直接交付？

如果问题只在模型，我们应该继续优化 Prompt、扩大上下文，或者换一个更强的模型。但从上面的验收项可以看到，缺口不只发生在生成环节： 模型还需要取得项目事实、执行外部动作、根据结果继续推进，并在越过风险边界前停下来。

本文就从这个问题开始：模型能力，要经过哪些环节，才能转化为可交付的企业生产力？

一、真正的差距，不在“能不能生成”，而在“能不能交付”

1. 模型演示和真实任务的条件不同

模型演示通常发生在受控条件下：输入清楚、上下文完整、输出边界明确。真实业务环境却很少这么理想。需求可能存在歧义，文档可能已经过期，工具调用可能失败，权限可能不足，执行到一半还可能需要人工确认。

因此，模型在单次测试中表现很好，只能证明它具备某一步所需的理解或生成能力，不能直接证明整个应用可以稳定交付任务。

2. 从能力到交付，中间至少有三层

层次	主要回答的问题	页面开发中的例子
模型能力层	模型能否做好当前步骤的理解、推理或生成？	分析需求、生成 JSX、解释报错
任务闭环层	系统能否取得事实、执行动作并根据反馈继续推进？	读取 PRD、查询组件、修改文件、运行测试
工程保障层	整个过程能否被评价、观察、约束、恢复和改进？	权限控制、变更审计、失败恢复、质量评测

Agent 的官方文档也体现了类似的系统边界：它被描述为能够规划、调用工具、与专门角色协作，并保持足够状态来完成多步骤工作的应用。¹ 关键词不是某个模型名称，而是应用、工具、状态和多步骤工作。

由此可以先得到一个判断：模型能力影响系统理解与推理的上限，任务闭环和工程保障决定这种能力能否稳定转化为业务结果。

二、一个页面开发任务，为什么不是一次 Prompt？

1. 先区分“生成一步”和“交付任务”

如果任务只是生成一个独立组件、把 JavaScript 改成 TypeScript，或者解释一段报错，单次模型调用往往就是成本最低、响应最快的方案。Prompt 没有失效，问题在于我们有时会把“模型能生成任务中的某一步”，误认为“模型能交付整个任务”。

以违规处置列表页面为例，模型只看一句需求时，可以根据通用知识猜出页面结构：

• 搜索表单；
• 数据表格；
• 分页；
• 处置按钮；
• 加载和空状态。

这些内容看起来合理，却还不能证明它适配当前项目。项目使用哪套组件库？筛选条件来自哪里？处置按钮受什么权限控制？分页字段叫 pageSize 还是 size？这些事实不在模型的通用知识里。

2. 企业交付面对的是任务链

任务要求	单次模型调用	完整应用系统
理解需求	只能依据输入中的文字	可读取 PRD、补充材料并请求澄清
复用组件	可能按通用经验生成	可搜索代码仓库和组件文档
接入接口	容易猜测字段和返回结构	可读取 API 定义并校验类型
遵循规范	依赖 Prompt 是否完整列出	可加载仓库规则、模板和示例
验证结果	生成后即结束	可运行 lint、测试和构建
处理失败	等待用户再次提问	可读取错误反馈并决定修正或暂停
控制风险	难以仅靠文字保证	可限制工具权限并设置人工确认点

差距主要来自三类复杂性。

• 多步骤。 后一步依赖前一步的结果。接口尚未确认，代码生成得再快，也可能只是更快地产生返工。

• 多系统。 真实信息分散在需求文档、代码仓库、组件平台、接口文档和 CI 环境中。模型并不会天然拥有这些数据与权限。

• 持续判断。 搜索不到组件怎么办？测试失败后应该修改实现还是补充配置？发现需求和接口冲突时是否继续？每一次环境反馈都可能改变下一步。

模型产生结构化调用，真正的操作由应用或平台执行。² 这意味着“模型建议调用什么”和“系统是否允许、如何执行”是两件事。任务闭环来自模型决策与确定性执行的配合，而不是把数据库或仓库权限直接交给模型。

三、从生成响应到完成任务，中间多了一个闭环

1. 单次模型调用：输入到响应

最简单的 LLM 应用可以表示为：

它适合边界清楚、无需持续访问外部环境的任务，例如总结、改写、分类或生成一个独立代码片段。系统的核心产物是一次响应。响应返回后，本轮工作结束。

2. Workflow：用固定路径组织多个步骤

当任务可以稳定拆成若干步骤时，可以用 Workflow 把模型和工具串起来。

一种常用的架构区分是：Workflow 由预定义代码路径编排 LLM 与工具；Agent 则由 LLM 动态决定过程和工具使用。³

例如，一个固定的页面生成流程可以是：

步骤提前确定，失败分支也可以在代码中写清楚。这类任务使用 Workflow，通常比开放式 Agent 更容易测试和维护。

3. Agent：根据环境反馈决定下一步

如果无法预先知道需要查哪些文件、调用几次工具、遇到错误后走哪条路径，就更适合考虑让模型参与过程决策。

一个公开、可观察的 Agent 执行循环可以概括为：

Agent 需要从工具结果、代码执行等环境反馈中取得可核验的事实，并据此判断进展；遇到检查点或阻塞时，可以返回给人处理。³ 普通 ChatBot 或单轮调用即使使用了 LLM，如果模型并不控制任务的后续执行，也不属于这里讨论的 Agent。⁴

4. 三者不是新旧替代关系

形态	路径由谁决定	适合场景	主要代价
单次调用	一次输入直接得到响应	边界明确、无需外部动作	难以完成多步骤任务
Workflow	代码预先定义	步骤稳定、强调一致性	对开放变化适应有限
Agent	模型在边界内动态选择	步骤难预知、需要环境反馈	成本、延迟和错误累积风险更高

Agent 不是 Prompt 的“高级版”，Workflow 也不是“低级 Agent”。它们对应不同确定性的任务。工程上应从最简单的可行方案开始，只有当动态决策确实改善结果时，才引入多步骤 Agent。³

四、从任务闭环到生产系统，还缺什么？

第三节解释了 Agent 如何借助环境反馈形成任务闭环。但闭环能够运行，不等于任务已经具备生产可用性：执行可能中断，所有接口也可能正常返回，最终结果却仍然偏离用户目标。

1. 从一次 Response 到一次 Run

普通模型调用的核心对象是一次 Request/Response，Agent 的工程对象则更接近一次 Task 或 Run。一次 Run 可能包含多次模型调用和工具执行，也可能在提交代码等节点暂停，等待确认后再继续。

因此，应用需要用 State 记录目标、已完成步骤、工具结果、等待中的输入以及恢复位置。循环、状态、可恢复审批和人工复核共同围绕一次 Run 工作。¹ 任务只有在中断后可以恢复、失败后可以继续处理时，才算拥有可管理的生命周期。

2. 接口成功不等于任务成功

传统服务关注错误率、延迟、吞吐量和资源使用，这些指标在 AI 应用中仍然重要，却不能单独回答“任务完成得好不好”。一次 Agent 运行可能所有 API 都返回 200，最终却读取了过期文档，或者生成的代码能够构建，却遗漏了权限分支。

这类系统具有非确定性和复杂性，观察范围需要覆盖模型交互、工具使用、执行路径、状态变化、安全和质量，而不仅是接口是否成功。⁵ 日志和 Trace 也需要纳入检索来源、工具调用、权限与执行结果，并与评测和治理连接。⁶

工程问题	对应能力	页面开发中的典型信号
能否评价	Evaluation	需求覆盖、测试结果、工具选择是否合理
能否观察	Logs / Metrics / Trace	哪一步失败、调用次数、延迟和成本
能否约束	Guardrails / 权限控制	允许读取哪些仓库、哪些动作需要确认
能否改进	评测集 / 回归机制	线上失败能否转成后续测试用例

这四类能力把质量判断从“最终文字是否流畅”扩展到任务结果和执行过程。真实失败还应沉淀为评测任务，用于验证后续修改是否引入回归。⁷

3. 自主执行仍然需要风险边界

Human in the loop 不等于每一步都弹出审批框，也不意味着所有动作默认放行。更合适的方式是按风险分层：

• 只读搜索可以在授权范围内自动执行；
• 文件写入限制在指定工作区，提交前展示变更；
• 发布、删除、付款等高风险动作必须人工确认。

遇到阻塞或只有用户才能决定的偏好时，系统也应暂停并请求反馈。³ 所谓“自主”，是系统在授权边界内连续推进，同时让人保留监督和干预能力。

这些能力共同构成三层框架中的工程保障层：任务闭环不仅要能运行，还要可管理、可评价、可约束。

五、什么时候需要 Agent，什么时候不需要？

讨论到这里，容易走向另一个极端：既然真实任务需要闭环，是不是所有 AI 应用都应该改造成 Agent？

答案是否定的。Agent 会引入更多模型调用、工具交互和状态管理，也意味着更高的延迟、成本以及错误累积风险。没有明确收益时，增加自主性只是在增加系统复杂度。

1. 把选择收敛为五个问题

前面已经说明三种形态不是新旧替代关系。落到方案设计时，可以把选择收敛为五个问题：

1. 一次调用能否可靠完成？ 如果输入和输出边界清楚，不必增加循环。
2. 步骤能否预先确定？ 如果路径稳定，优先使用 Workflow。
3. 是否必须访问外部事实或执行动作？ 如果不需要，工具和状态可能都是额外负担。
4. 能否获得明确的环境反馈？ Agent 需要根据测试结果、工具返回等事实判断进展。
5. 收益能否覆盖成本和风险？ 灵活性不是免费的，尤其是高频和高风险任务。

开放问题难以预先确定步骤时，Agent 更有价值；任务路径清晰时，简单调用或 Workflow 往往已经足够。³

这五个问题仍然落在前文的三层框架中：先判断模型能不能做好单步工作，再判断任务是否需要动态闭环，最后确认成本和风险是否可控。三层之间有依赖，但不是产品成熟度排行榜。

2. 回到页面开发案例

同一个“生成页面”需求，根据任务范围不同，方案也不同。

问题特征	推荐形态	原因
根据明确字段生成一个表格组件	单次调用	输入、输出和完成条件都清楚
按固定模板生成页面并依次运行校验	Workflow	步骤稳定，可由代码编排
在现有仓库中自主查找组件、修改文件、测试并修正	Agent	路径依赖环境反馈，难以预先写死
涉及发布生产或高权限数据修改	优先确定性流程；确需 Agent 时增加人工确认	高风险动作不应仅由模型动态决定

这个判断也能迁移到其他场景。

客服问答可能只需要检索和生成；退款处理需要读取订单、判断规则并调用工具；超过额度的退款还需要人工审批。运营报告可以由固定 Workflow 生成；面对数据异常时，是否允许 Agent 自主扩大查询范围，要看数据权限、反馈质量和风险。

不是所有业务都需要 Agent；一旦系统开始代表用户连续执行任务，就应同步设计与风险相匹配的工程保障。

六、这就是本文所说的 AI 应用工程

回到开头。模型能根据一句 Prompt 生成 React 页面，只证明它具备了任务中的代码生成能力；当系统还要取得上下文、调用工具、保存状态、处理失败、评测结果并控制权限时，建设对象已经从模型扩展为完整的 AI 应用。

广义的 AI Engineering 本来就关注 AI 系统如何走出受控环境。CMU 软件工程研究所（SEI）将它描述为结合系统工程、软件工程、计算机科学和以人为本设计，在复杂、模糊、动态的真实环境中构建 AI 系统的研究与实践领域。⁸

本文讨论的范围更窄：围绕基础模型构建任务闭环，并通过软件工程手段让 AI 应用可运行、可评价、可观察、可约束、可持续改进。

这就是我说的 AI Application Engineering（AI 应用工程）。

它不等于"选一个更强的模型"，也不等于"套一个 Agent 框架"。模型、Prompt、Tool、Workflow、Agent 和平台能力各自处理不同层面的问题。工程工作的价值，在于把它们组合成符合业务目标和风险边界的系统，并用运行反馈持续改进。

总结

这篇文章只需要带走三个判断：

1. 模型能力是起点，不是企业生产力本身。
2. 从响应到任务，需要上下文、工具、状态和环境反馈构成闭环。
3. 从 Demo 到生产，需要评测、可观测性、边界控制与人工协作。

下一篇，我们会进入 Agent 内部，拆解一个任务循环到底如何运行：模型负责什么，工具如何被调用，状态怎样更新，系统又在什么条件下继续、暂停或结束。

---

Footnotes

1. OpenAI, “Agents SDK”, developers.openai.com/api/docs/gu… （official-doc） ↩ ↩²

2. Anthropic, “Tool use with Claude”, docs.anthropic.com/en/docs/bui… （official-doc） ↩

3. Anthropic, “Building effective agents”, www.anthropic.com/engineering… （official-blog） ↩ ↩² ↩³ ↩⁴ ↩⁵

4. OpenAI, “A practical guide to building AI agents”, openai.com/business/gu… （official-blog） ↩

5. Google Cloud, “Agent observability”, docs.cloud.google.com/stackdriver… （official-doc） ↩

6. Microsoft Learn, “Observability for Generative AI and agentic AI systems”, learn.microsoft.com/en-us/secur… （official-doc） ↩

7. Anthropic, “Demystifying evals for AI agents”, www.anthropic.com/engineering… （official-blog） ↩

8. CMU Software Engineering Institute, “AI Engineering”, www.sei.cmu.edu/artificial-… （official-doc） ↩