AI Agent 的工程化被低估了

近期热度较高的两篇文章[1][2]，不约而同的提到了 AI 发展至今，工程化对 AI 应用的作用被低估了。

• “比如更好的虚拟机、更长上下文、大量的 MCP、甚至智能合约……等等一系列工程问题都是巨大的需求。”

• “AI 的工程化工具很多，例如 LangGraph、LangChain，这些都是用于搭建的乐高积木，积木越丰富，组装成复杂结构的能力就越强。”

但工程化一词是很泛化的技术用语，包含的内容极广。广义的讲，非算法类的技术实现和产品设计，都可以归类为工程化。本文暂把工程化分类为产品工程和技术工程，试图通过这个视角，去简单拆解构建 AI Agent 的工程化体系。

工程化 = 产品工程（Product Engineering）+ 技术工程（Technical Engineering）

这两部分协同决定了一个 AI Agent 是否「能用、好用、规模化可用」。

目标：让 AI 能用和好用，用户用得明白、用得舒服、用得下去。从增长的视角就是，不仅要下载量，还要留存率和活跃度。

产品工程在乎的是产品哲学、产品商业、交互设计和用户体验等综合思考，让 AI 不再只是“黑箱”，而是能做到有感知、有引导、有反馈，并且具备自我纠错的机制。我们先对产品工程做一个拆解，然后选择一些重点模块进行展开阐述它们在成就一款成功的 AI Agent 中所起到的作用。

在传统软件开发中，我们会先问“用户的核心痛点是什么”。AI Agent 也一样，如果不搞清楚使用对象和场景，很容易做成“看上去什么都能回答，但什么也用不起来”的尴尬局面。

构建 AI Agent 的第一步，不是选模型，而是要像产品经理一样回答一个问题：“这个 AI 要帮谁，如何解决，解决什么问题，问题能解决到什么程度，这个作用用户是否有意愿付费？”也就是产品和市场的契合点。

拿 Manus 来举例[3]，它是全球首款通用 AI 智能体，其核心理念是“手脑并用”，强调 AI 从被动工具转变为主动协作者。

1. 明确 AI 的角色定位

在需求建模阶段，Manus 将 AI 定位为“主动协作者”，能够独立思考、规划并执行复杂任务，而不仅仅是提供建议或答案。

示例： 用户输入“泰国海岛游7日预算2万元”，Manus 自动完成汇率换算、酒店比价、行程规划并导出 PDF 手册。

这种角色设定要求在系统提示词中明确 AI 的职责和行为边界，确保其在执行任务时具备自主性和可靠性。

2. 任务闭环能力的设计

Manus 强调任务的闭环执行能力，即从接收指令到交付完整成果的全过程自动化。

示例： 用户请求对 xx 股票进行分析，Manus 自动获取相关数据，进行财务建模，生成交互式仪表盘，并部署为可访问的网站。

在需求建模中，需要将用户需求拆解为多个子任务，并设计相应的执行流程和工具调用策略，确保任务能够顺利闭环。

3. 多智能体协同架构

Manus 采用多智能体架构，分为规划层、执行层和验证层，各层协同工作以完成复杂任务。

• 规划层：
  负责任务拆解和流程规划。
• 执行层：
  调用各种工具和 API 执行具体任务。
• 验证层：
  对任务结果进行校验，确保输出的准确性和合规性。

  
  

在需求建模阶段，需要定义各层的职责和交互方式，确保整个系统的协同工作。

4. 人机协作模式的创新

Manus 支持异步处理和中途干预，用户可以在任务执行过程中追加指令或修改任务参数，模拟真实职场中的协作模式。

示例： 用户在 Manus 执行任务过程中，可以随时关闭设备或追加指令，Manus 会根据新的指令调整任务执行流程。

这种设计要求在需求建模中考虑人机交互的灵活性和可控性，确保用户在协作过程中具有足够的控制权。

这种需求建模的方式类似于将用户的任务流程分段，并找出 AI 最擅长、最值得介入的环节，既避免了“大而泛”，又让用户第一时间感受到效率提升。

就像设计微服务的服务边界，哪些职责是订单单元负责，哪些职责是用户库存单元负责，AI 应用中，一样需要明确功哪些是 AI 负责的，哪些是业务逻辑兜底的，这些都将直接决定应用的最终体验。

AI Agent 不同于传统软件，它的输出常常是不确定的、延迟的、难预测的，这也意味着 UI/UX 设计不仅是“界面美观”，更是对用户心理与行为节奏的把握。

举个例子，DeepSeek 首次将大模型的“思考过程“可视化，在生成响应前，会展示模型的思维链，让用户知道：AI 并非乱猜，而是有逻辑地在思考。用户不再被动接受结果，而是参与思考过程，建立共同解题的伙伴关系。

这种设计有效提升了用户的信任度与接受度，尤其在多步骤任务、复杂文档总结、跨信息引用的场景。

目前，“渐进式信息呈现”、“思路可视化”、“结果结构化”等交互策略已经成为 AI Agent 的标配。用户可以查看调用链路、追踪引用来源等。甚至，Qwen 还提供了引用来源的删除选项，进一步降低了不可信互联网来源导致的幻觉。

系统提示词（System Prompt）是 AI Agent 开发者预设的一组指令或约束，用于定义模型在特定应用场景中的行为框架、角色设定、交互风格和输出规则。它与用户在前端直接输入的查询（User Prompt）不同，属于更底层的控制机制，对模型输出内容的质量、风格、一致性和安全性具有决定性影响。其核心构成要素通常包括：角色定义、行为约束、任务导向以及上下文管理。[4]

举个例子，NotebookLM 的核心理念是：用户上传自己的资料，而 AI 助理基于这些资料回答问题、提供建议，充当“可信任的知识顾问”，赋能用户进行更高效、更智能的学习与研究活动。

这种产品定位决定了，NotebookLM 背后的系统提示词不仅要完成基础的语言引导，还要实现更复杂的任务指令与安全约束。我们可以从几个关键维度来拆解其系统提示词设计思路：

1. 角色定义：你是我的研究助理

NotebookLM 的系统提示词会将模型设定为“文档知识顾问”，强调它只能根据用户上传的笔记、PDF、网页等提供答案。这一点非常关键，它确保了模型的回答不会随意“发挥”或引入幻觉信息，而是始终围绕用户提供的内容展开。

prompt你是一个研究助手，你的职责是帮助用户理解他们上传的文档内容，回答问题时仅引用这些资料，不做主观推测。

这种角色设定不仅控制了模型的输出范围，也让用户心理上更容易信任回答的来源。

2. 行为约束：引用并注明资料

NotebookLM 强调答案必须「引用资料出处」，这就需要系统提示词明确要求模型在回答时附上对应文档和段落链接。开发者通常会在提示词中加入这样的约束：

prompt在回答每一个问题时，引用文档中相关段落，并用 markdown 格式列出其标题与段落索引。

这使得用户在阅读模型回答时，可以随时回溯验证来源，形成良好的可追溯体验。对 AI 输出质量的信任，往往来自于这种“有出处”的设计。

3. 任务导向：以提问为驱动的内容生成

NotebookLM 不仅回答问题，还支持结构化内容生成，如自动总结文档、生成研究大纲等。每种任务模式都会使用不同的系统提示词。例如，在总结模式下，提示词可能这样引导模型：

prompt请根据用户提供的文档，提炼出 5 个最重要的观点，并逐条列出，语言风格保持客观、中性，不做扩展解释。

任务导向的 Prompt 编排，已经超越了传统“对话式问答”的范畴，像是一种“任务脚本”，为多模态的 AI 应用埋下能力基础。

没有哪个 AI Agent，输出的内容一开始就是准的。现实的情况是它在某些输入下表现不佳、在某些数据下语义偏差，这时就需要收集“失败案例”，形成从输入到评估的闭环。

比如 Monica 的记忆功能，当用户浏览推荐的记忆条目时，若点击了“采纳为事实”，这些内容就会写入记忆数据库，供后续对话中调用；而用户不采纳的，则不会被强记。这种“反馈 → 选择性吸收 → 下一轮调优”的机制，就是对传统 Prompt + Chat 模式的增强。

Monica 会通过用户特征的持续学习，提升需求理解的精度和响应准确性。本质是在对话式交互中重建了上下文感知机制。就好像人与人之间交流，相处时间越长，越熟悉彼此，越能理解对方所表达的。

目标：让 AI 背后那套系统启动的快、跑得稳、扩得动、看得清

技术工程用于验证产品工程。和互联网时代的快鱼吃慢鱼类似，AI 时代也同样看中技术工程效率，第一时间跑通产品工程，进行市场验证，并快速迭代。技术工程是支撑 AI 应用的后勤系统，涵盖架构与模块化、工具调用机制、模型与服务集成、流量和访问控制、数据管理与结构化输出、安全与隔离机制、DevOps 与可观测性等。

在 AI 应用从原型走向生产系统的过程中，一个关键挑战在于如何将多个异构的模型能力，如提示（Prompt）、模型增强（The Augmented LLM）、顾问（Advisors）、检索（Retrieval）、记忆（ChatMemory）、工具（Tool）、评估（Evaluation）、MCP，通过统一架构组织起来，并实现高可维护性、可观测性和可扩展性。这正是模块化架构与流程编排工具发挥作用的地方。

除了 LangChain、LangGraph 这类以 Python 为主的生态，Spring AI Alibaba 为 Java 群体提供了原生、企业级的 AI 应用编排能力，成为构建模块化 AI 应用的重要工具之一。它的核心功能除了上方提到的8个基础能力，还提供了：

• Multi-agent 多智能体框架：Graph 是 Spring AI Alibaba 社区核心实现之一，也是整个框架在设计理念上区别于 Spring AI 只做底层原子抽象的地方，Spring AI Alibaba 期望帮助开发者更容易地构建智能体应用。
  
• 通过 AI 生态集成，解决企业智能体落地过程中关心的痛点问题。Spring AI Alibaba 支持与百炼平台深度集成，提供模型接入、RAG 知识库解决方案；支持 ARMS、Langfuse 等可观测产品无缝接入；支持企业级的 MCP 集成，包括 Nacos MCP Registry 分布式注册与发现、自动 Router 路由等。
• 探索具备自主规划能力的通用智能体产品与平台。社区发布了基于 Spring AI Alibaba 框架实现的 JManus 智能体，除了对标 Manus 的通用智能体能力外，我们的目标是基于 JManus 探索自主规划在智能体开发方向的应用，为开发者提供从低代码、高代码到零代码构建智能体的更灵活选择。

假设你正在开发一个面向企业内部的智能客服系统，要求支持：

• 多轮对话，能记住用户上下文；
• 接入内部知识库，进行检索增强；
• 调用 ERP、CRM 等后端系统的接口；
• 可在 K8s 上部署，支持高并发、统一日志追踪。

  
  

使用 Spring AI Alibaba 可以这样设计系统：

大模型能力很强，但相比完全由人为的业务代码架构的经典应用，引入了不确定性，这需要加强流量和用户访问控制进行对冲，从而保障可用性、费用，防止被滥用。经典应用升级到 AI Agent，新增了 LLM 和 MCP Server 两个信息处理环节。AI 网关在 AI Agent、LLM 和 MCP Server 三者间扮演了流量和用户访问控制的角色。（如下图）

流量控制：

• key-rate-limit：对每个访问密钥（API Key）设置访问频率上限。例如，每秒最多10次请求。例如免费用户每天只能调用 AI 接口 100 次，而付费用户可以调用 10,000 次。
• http-real-ip：在多层代理环境下获取用户的真实 IP 地址。例如，识别恶意访问者真实地址，有人用 VPN 频繁注册账号。判断用户从哪个国家或地区来，便于后续做内容推荐或风控策略。
• HTTP Strict Transport Security：强制客户端通过 HTTPS 通信，防止中间人攻击。一是保护敏感数据，AI 聊天记录、训练数据上传、推理请求等都必须加密传输。二是政府或金融机构 AI 接入的情况下，要求安全等级高，确保数据不会在传输过程中被监听或篡改。
• canary-header：根据请求头的特定标记，决定是否把请求发送给“金丝雀版本”（Canary）的服务。例如，灰度发布 AI 模型，上线新版本的 GPT 接口，先让 5% 的用户使用，如果没问题再全面推开。A/B 测试：测试两个提示词模板或两个微调模型效果差异，只有携带特定 header 的请求才路由到测试版。
• traffic-tag：给请求打上特定标签，并基于这些标签做策略控制。例如，模型多版本调度，同一条问题，根据“付费用户”、“新用户”标签，分别送到不同模型版本（比如 Qwen3 32B he Qwen3 235B）。个性化策略路由,开发者根据用户行为打标签，如“图像偏好”、“代码请求多”，路由到定制处理链路。
• cluster-key-rate-limit：跨多节点网关实例设置统一的访问频率控制，以集群方式限流。例如用于高可用的 AI 服务平台，在多个地区部署 AI 网关，仍能对某一用户设定总访问次数上限，防止绕过单点限流。保护后端模型资源：在节假日或热点话题爆发时统一限流，防止大模型资源耗尽。

用户访问控制：

• key-auth：通过预分发的 API Key 实现鉴权。客户端必须在请求中携带特定的 Key 才能调用服务。例如开放平台，要求开发者注册账号后拿到自己的密钥才能调用接口。以及Webhook 验签，内网服务或 BFF 层在调用网关服务时通过 Key 进行简单的身份认证。
• basic-auth：基于 HTTP Basic Auth 的用户名和密码认证方式。客户端在请求头中以 Base64 编码方式传输凭证。例如低复杂度的内部认证机制，在企业内部测试或早期原型阶段，快速保护接口。以及 AI 内部工具访问控制：一些可视化分析面板、提示词管理平台等，先用 Basic Auth 快速加门。
• hmac-auth：基于 HMAC（Hash-based Message Authentication Code）的签名认证机制。每个请求都携带签名值，网关根据密钥验证签名是否有效。例如 Webhook 回调验证，第三方平台（如 Stripe、OpenAI）发送事件时附带签名，验证来源是否可信。防篡改接口保护，某些敏感接口（如下发推理任务）用签名保护请求是否被改过。就像寄包裹前在封条上盖上专属印章，接收方看到印章正确才确认这个包裹没被动过。签名常基于请求体 + 时间戳 + 密钥生成哈希，防止重放和伪造请求。
• jwt-auth：通过 JWT（JSON Web Token）实现用户认证与授权。请求中携带签发的 JWT，网关根据签名与载荷判断是否有效。例如用户用户身份认证，用户登录后获取 Token，用于访问 AI 助手、会话系统等服务，以及角色权限控制，JWT 中嵌入角色信息，比如 role=admin，网关据此放行或限制访问。像是拿到了一张写着“我是 VIP 客户”的数字通行证，系统会扫一眼证件确认身份和权限，常用于前后端分离架构、支持 SSO（单点登录）的企业系统。
• jwt-logout：实现 JWT 的失效机制，虽然 JWT 自带过期时间，但一旦用户主动登出，需要从系统层面使其失效。例如安全场景强化，用户注销后，不希望旧 Token 还能继续调用模型接口。AI SaaS 平台中的会话控制：一旦用户换设备、注销登录，需要主动清理其身份凭证。就像把别人发给你的门禁卡注销掉，避免即使它还有效期也继续使用。
• oauth：基于 OAuth 2.0 协议，实现三方授权登录与访问控制。用户可以通过 Google、GitHub、微信等授权平台登录。例如一键登录，Agent 允许用户用 Google 登录，授权后获取身份 Token，以及集成企业身份系统。

此外，Higress / 阿里云 API 网关为代表的 AI 网关，通过灵活可扩展的插件机制，在网关层扩展了更多的能力，用户也可以开发自定义插件来丰富插件能力。

• AI 检索增强生成：通过对接向量检索服务（DashVector）简化 RAG 应用的开发，优化大模型的生成内容。
• 安全合规：在网关进行输入输出拦截：内容安全防护策略具备对网关请求和响应内容进行实时扫描的能力，以识别潜在的风险信息。在大模型层进行输入输出拦截：通过对大模型的输入和输出进行实时检查，确保潜在的风险信息不会被无意间暴露或传播，从而降低数据泄露的风险。在联网搜索引擎层拦截，检测搜索引擎响应内容，以识别潜在的风险信息（如违规信息、恶意链接、敏感信息等）。
• 内容缓存：在重复性强的 AI 请求场景，通过将大语言模型生成的响应结果缓存到 Redis 数据库中，避免重复调用大语言模型，提升响应速度。

经典互联网应用，一切的调试都有依可循，但大模型应用缺少标准化的调试工具，问题跟踪、问题定位、解决问题都面临更大的挑战。以下是几个关键对比维度和核心差异。

可观测的对象差异：从代码执行 → 到模型行为

例如，经典应用关注“这个接口有没有超时”，大模型应用则还得关注“这个模型为什么说了不该说的话”、“它是不是误解了用户意图”。

可观测目标的变化：从可用性 → 到语义正确性

对传统系统而言，可观测的目标是系统是否正常运行，比如：响应是否超时，CPU、内存是否告警，错误率是否飙升。对大模型应用而言：系统可能运行正常，但结果却错了！可观测目标不仅要关注可用性的指标，还要关注

• 响应内容是否正确合理（语义正确性）
• 是否偏离设定行为（如系统角色）
• 是否存在幻觉、越权、毒性语言
• 模型行为是否与版本、Prompt、上下文相关

例如，一个 AI 医疗问答系统没有任何崩溃日志，但模型输出了“不建议吃感冒药”的错误建议，这种错误需要语义层的可观测。

针对以上问题，我们首先要解决的是一次调用到底经过了哪些组件，然后通过调用链把这些组件全部串联起来。要实现全链路的诊断，首先要把这些链路打通，当一个请求出现问题的时候，到底是哪个环节出问题了，是 AI 应用还是这个模型内部推理出现了问题，快速界定。[5]

第二需要构建一个全栈的可观测数据平台，它能够把所有的这些数据之间能够很好地关联起来，不仅是链路，还包括指标，例如模型内部的一些 GPU 利用率，通过关联分析能知道到底是应用层出问题，还是模型底层出问题了。

最后我们还需要通过一些模型日志，了解每次调用的输入输出是什么，并利用这些数据做一些评估和分析，来验证 AI 应用的质量。

从这三个手段入手，从监控的领域来说，我们在不同层面分别为大家提供了一些观察手段和核心关注点。

尽管本文尝试梳理 AI Agent 工程化的核心模块与关键路径，但我们必须承认，现实中的挑战远比文中所描述的更为复杂。无论是人为逻辑和大模型的有机协作、复杂任务的处理范式、生成内容的评估标准，每一环都隐藏着大量尚未解决的产品与技术工程细节。工程化从来不是锦上添花，它是将模型能力落地为真实生产力的唯一通路。

更重要的是，AI Agent 工程化的推进，不只是 Agent Builder 的课题，更关乎整个行业的演进。只有在开发平台、流量和访问管控、工具链、可观测性、安全等多个维度持续投入，构建出稳定可靠、易于复用的应用基建，才能真正带动上层 Agent 应用的规模化落地，推动形成面向大模型的新一代“应用供应链”生态。