企业官网建设流程全解析

过去一年，Agent 这个词被用得太多了。多到很多团队一提 AI 应用，就默认要做 Agent；一提 Agent，就默认要接模型、配工具、写 Prompt、套框架。热闹是热闹，但真正落到企业生产环境里，问题很快会变得没那么浪漫。

一个 Demo 级 Agent 可以靠模型能力撑起来。一个要服务真实业务、真实用户、真实组织流程的 Agent，靠的就不只是模型了。它要处理状态、权限、工具、失败恢复、审计、成本、评测、组织协作。这里面任何一项没想清楚，都会在上线后变成很具体的工程问题。

阿里云在云栖大会发布的Alibaba Cloud AI Agent Handbook，值得关注的地方不只是又多了一本白皮书，而是它把 Agent 从“模型能力展示”拉回到了“工程系统建设”。尤其是其中提出的“智能面积”，对企业今天怎么投 AI、哪些东西该自建、哪些东西该复用，有比较现实的参考价值。

一、Agent 的问题变了

去年很多企业做 AI 原生应用，核心诉求还停留在“怎么把模型接进业务系统”。这类问题相对清晰：选模型、接 API、做 RAG、设计 Prompt、加一层权限和日志，大体就能做出一个可演示的应用。

但 Agent 起来之后，问题开始变复杂。

它不再只是一次请求、一次生成、一次返回。Agent 往往要在一个较长任务里持续行动：理解目标、拆解步骤、调用工具、读取外部环境、根据反馈调整计划，必要时还要暂停、恢复、回滚、等待人工确认。

Coding Agent 是最典型的例子。Codex、Claude Code、Qoder 这类产品，已经不只是“帮你写几行代码”。它们会读取仓库、维护任务计划、修改文件、运行终端、执行测试，并在过程中接受人的反馈。

这件事对架构设计的冲击很大。

过去应用调用模型，更像调用一个增强版函数：

Input -> Model -> Output

现在 Agent 更像一个运行中的任务系统：

Goal -> Plan -> Act -> Observe -> Adjust -> Verify

如果任务短、工具少、风险低，很多复杂性可以先被忽略。但一旦进入企业场景，比如审批、交易、客服、运维、安全、财务、供应链，模型每一次行动都可能影响真实业务状态。这时就不能只问模型聪不聪明，还要问系统是否可控、可观测、可恢复。

这也是 Handbook 重新梳理架构的背景：原来的 AI 原生应用白皮书，已经很难覆盖 Agent 工程化、规模化、组织化带来的新挑战。

二、Agent 不只是 Model

Handbook 里一个关键判断是：Agent 由 Model 与 Harness 共同构成。

这个判断很重要。因为它把 Agent 的架构边界从“模型能力”扩展到了“模型之外的工程系统”。

Model 负责推理、生成、规划、判断。Harness 则负责把模型能力放进一个可运行、可约束、可持续改进的系统里。里面包括上下文组织、任务状态、工具控制、环境隔离、失败恢复、结果评估、风险约束等一整套机制。

可以用一个简化图来理解：

很多团队早期做 Agent，会把大量注意力放在模型选择上：哪个模型推理更强、哪个模型上下文更长、哪个模型工具调用更稳定。这当然重要，但如果 Harness 很弱，模型能力很容易被浪费。

比如：

• 上下文组织不好，模型拿不到关键业务事实；
• 状态管理缺失，长任务一中断就无法恢复；
• 工具契约混乱，模型调用工具时经常传错参数；
• 权限边界模糊，Agent 可能执行超出授权范围的操作；
• 缺少评测集，效果好坏只能靠主观感受。

这些问题不是换个更强模型就一定能解决。模型越强，反而越需要 Harness 把它约束在正确的业务轨道里。否则它可能更快地做错事。

这也是 Agent 工程化的现实感：智能提升不等于复杂性消失，很多复杂性只是从“人写业务逻辑”转移到了“系统如何组织模型行动”。

三、从构建到运行，中间隔着生产环境

Agent 在本地跑通，和在企业里长期运行，是两回事。

开发环境里，一个 Agent 失败了，最多重跑一次。生产环境里，一个任务失败，可能会带来重复执行、状态不一致、用户无感知等待、人工介入成本，甚至业务风险。这个差别很容易被 Demo 掩盖。

Handbook 按照“架构-构建-运行-治理-调优”的生命周期展开，背后其实对应了 Agent 落地的几个关键责任域。

架构阶段决定边界

Agent 一开始就要回答几个问题：

• 这个场景是否真的需要 Agent？
• Agent 拥有多大的自主权？
• 哪些步骤必须人工确认？
• 哪些能力由业务应用实现，哪些能力下沉到共享平台？
• 怎样算任务完成？
• 出错后由谁恢复，怎么恢复？

这些问题如果留到构建阶段再处理，后面大概率会返工。很多团队做到这里会卡住，不是技术不会写，而是业务边界和风险边界没有定清楚。

构建阶段组织任务过程

构建 Agent 的核心，不只是写 Prompt，而是把模型的离散判断组织成一个可持续推进的任务过程。

以 Coding Agent 为例，它之所以比较容易率先成熟，是因为软件研发场景天然有一些可验证机制：代码仓库、文件 diff、编译结果、测试用例、CI 输出。模型的行动可以被工具和结果反馈闭环起来。

但企业里很多场景没有这么理想。

客服场景的成功标准可能是用户问题解决；审批场景的成功标准可能是流程合规；运维场景的成功标准可能是故障恢复且不能扩大影响。不同场景的状态、权限、验证方式完全不同。

所以更合理的做法，是复用 Coding Agent 里可泛化的 Harness 机制，而不是照搬它的流程。

这里的工程权衡很明显：
如果把所有能力都写在单个 Agent 应用里，短期迭代快，团队掌控感强；但应用一多，状态、权限、工具、审计、评测会重复建设，后期维护成本很高。
如果一开始就建设统一平台，长期复用性更好，但前期抽象难度高，容易做成“大而全”的平台工程，业务还没跑起来，基础设施先复杂了。

比较稳妥的路径，通常是先在高价值场景里把 Harness 跑实，再把共性能力逐步下沉，而不是一开始就追求完美平台。

四、运行层是规模化的分水岭

Agent 一旦对外服务，就必须面对稳定性、安全、性能和成本。

这些词听上去很传统，甚至有点“老后端”的味道。但越是新技术，越绕不开这些老问题。尤其是 Agent，因为它运行时间更长、外部依赖更多、行为路径更不确定，运行层的重要性比普通应用更高。

几个问题很具体：

• 任务跨请求、跨进程之后，状态存在哪里？
• Agent 执行工具时，运行环境如何隔离？
• 多个 Agent 同时工作时，如何协调？
• 工具调用失败后，是重试、降级，还是转人工？
• 长任务的成本如何控制？
• 用户关闭页面后，任务是否继续执行？
• Agent 的中间过程如何被追踪和审计？

传统 Web 应用大多是请求-响应模型，服务端处理完请求就结束。Agent 更像异步任务系统、工作流引擎、事件驱动架构和模型推理系统的混合体。

一个更接近生产的运行架构，通常会出现这些组件：

这里最容易被低估的是状态外置。

开发阶段把状态放在内存里，问题不大。生产环境中，进程重启、任务中断、并发执行、重试补偿都会让内存状态变得不可靠。状态不外置，后面治理和调优也很难做，因为你看不到 Agent 走过的完整路径。

运行层还有一个现实约束：成本。

Agent 的多轮推理、长上下文、工具调用、失败重试，都会放大成本。如果没有模型网关、缓存策略、任务预算、超时控制和降级机制，一个看似效果不错的 Agent，可能在规模化后 ROI 直接崩掉。

所以企业做 Agent，不能只看单次效果，也要看单位任务成本、平均完成时长、人工接管比例、失败恢复成本。这些指标决定它能不能长期运行。

五、治理不是上线后的装饰

很多团队习惯把治理放到后面：先把功能做出来，后面再补观测、审计、权限、评测。

在传统系统里，这种做法已经有风险。在 Agent 系统里，风险会更高。因为 Agent 的行为路径并不完全由固定代码决定，它会根据上下文和模型判断动态变化。

治理要回答几个基础问题：

• Agent 实际执行了什么？
• 每一步用了哪些上下文？
• 调用了哪些工具？
• 是否越过授权边界？
• 是否被外部内容操纵？
• Prompt、Skill、MCP、Agent 依赖是否可管理？
• 上线前能否先验证行为？

这些东西如果没有记录，后续出了问题很难归因。模型答错了？上下文缺失了？工具返回错了？权限配置错了？流程设计错了？没有证据链，就只能靠猜。

Handbook 把治理拆成可观测、边界约束、资产管理、行为验证，这个划分比较贴近生产环境。

尤其是资产管理，后面会越来越重要。Prompt、Skill、工具描述、MCP Server、评测集、知识库、业务语义，这些都不是临时代码片段，而会逐渐变成企业 AI 资产。如果没有版本、权限、生命周期和复用机制，Agent 越多，组织内部会越乱。

六、调优的核心是归因

Agent 效果不好时，很多人的第一反应是换模型。这个动作有时候有效，但不一定解决根因。

真实系统里的问题可能来自很多层：

• 模型本身能力不足；
• Prompt 目标不清；
• 上下文缺少关键事实；
• 工具设计不适合模型调用；
• 工作流拆解不合理；
• 权限限制导致任务无法完成；
• 评测集覆盖不够；
• 业务规则表达不一致。

这些问题需要不同的优化方法。

如果是模型能力问题，可以考虑更强模型、微调、蒸馏或模型路由。
如果是上下文问题，重点在知识组织、记忆机制、检索质量和业务语义。
如果是工具问题，要改工具契约、参数结构、错误返回和幂等设计。
如果是流程问题，要调整任务拆解、人工确认点和失败恢复策略。

调优真正麻烦的地方在于：没有治理沉淀的证据，就无法归因。没有归因，优化就会变成玄学。

这也是为什么 Agent 的运行、治理、调优不能割裂看。运行提供过程数据，治理保证证据可信，调优把证据转成改进动作。三者形成闭环，Agent 才可能持续变好。

七、智能面积给企业划了一条投资边界

Handbook 提出的“智能面积”，是这次内容里比较有判断力的概念。

它把 Agent 能力放到两个维度里看：

• 横轴是通用智能，比如 Memory、Planner、Managed Runtime、Agent 协作；
• 纵轴是业务深度，比如业务事实、业务对象关系、业务语义、流程规则、行业经验。

模型公司和云平台会持续推进横轴。它们会把越来越多通用能力产品化、平台化、基础设施化。以前企业要自己写的 Planner、Memory、Router、重试、状态管理，未来一部分会逐步被模型或平台吸收。

企业真正应该长期沉淀的，是纵轴上的业务深度。

这个判断对企业选型很有价值。

如果一个能力明显会变成通用基础设施，企业没必要长期重仓自研。比如通用 Agent Runtime、通用工具调用协议、基础 Memory 能力、模型路由、基础可观测能力，很多都适合跟随云平台和开源生态。

但业务语义、流程规则、行业知识、企业内部数据关系、质量评测集，这些很难由外部平台替企业完成。

可以简单拆一下：

这就是“智能面积”的工程含义：企业不应该试图在所有方向都自建，也不能把希望全部押在模型升级上。横轴要复用，纵轴要沉淀。两者乘起来，才是最终生产力空间。

这里有个很现实的提醒：
如果企业只跟着模型能力跑，没有沉淀自己的业务资产，每次模型升级都会像重新开始。看似一直在追新，实际留下来的东西很少。
反过来，如果只埋头做内部知识库、流程配置和业务规则，不关注模型和平台演进，也容易造出一套很重但很快过时的系统。

比较好的策略，是在开放架构下沉淀业务资产。模型、框架、Runtime 可以替换，业务语义、工具契约、评测集和流程经验要能迁移。

八、Agentic OS 可能会成为下一层抽象

Handbook 最后一部分提到 Agentic OS。这个说法容易被误解成一个新操作系统，或者某个确定的产品类别。但从工程视角看，它更像是一组正在下沉的系统职责。

当一家企业同时运行多个 Agent、使用多种框架、服务多个租户时，一些能力会被反复实现：

• Agent 身份与权限；
• 工具注册与调用；
• 状态存储与恢复；
• 运行环境隔离；
• 多 Agent 通信；
• 观测、审计与评测；
• 资产管理；
• 成本控制。

如果每个 Agent 应用都自己做一套，短期没问题，长期会非常痛。标准不一致、日志不一致、权限不一致、工具接口不一致，最后治理成本会指数级上升。

Agentic OS 试图回答的，就是哪些能力应该从应用层下沉到系统层。

这类抽象不会一夜成熟，也不一定会以“OS”的形态出现。它可能先表现为云平台的 Agent Runtime、企业内部 AI 中台、MCP 生态、工作流引擎升级、模型网关扩展，最后逐步形成一套事实标准。

企业现在没必要为了 Agentic OS 这个概念提前造大平台，但应该在架构上留出位置：不要把所有能力都焊死在单个 Agent 里。尤其是工具、状态、权限、评测、观测这些模块，最好从第一天就考虑可抽离、可复用、可替换。

九、白皮书的价值变了

现在 AI 写作能力已经很强，白皮书这种形态看起来似乎没那么稀缺了。让模型生成一本几十页的技术文档，不是什么难事。

但工程类内容真正稀缺的，从来不是文字数量，而是判断。

哪些能力会平台化？哪些能力值得企业长期沉淀？一个 Agent 应该给多少自主权？业务边界放在哪里？什么时候该自建，什么时候该复用？这些问题不是简单堆资料能回答的，背后需要大量实践、失败经验和架构取舍。

Alibaba Cloud AI Agent Handbook 的价值，也不在于给出一个永远正确的答案。Agent 变化太快，今天的很多判断未来一定会被修正。更重要的是，它把 Agent 落地从“模型调用”推进到了“工程体系”，并且以开源方式持续维护，这对企业内部对齐概念、做选型、做立项，有实际帮助。

阿里云同时加入 Agentic AI Foundation，并成为 Gold Member，也说明 Agent 的竞争不会只停留在单个产品层面。未来很大一部分竞争会发生在开放标准、工具协议、运行时、生态协作和企业落地经验上。

对企业来说，现阶段更稳的做法不是押注某个框架，也不是急着自研全套 Agent 平台，而是把几个问题想清楚：

• 模型和通用 Harness 能力，尽量采用开放、可替换方案；
• 业务知识、语义、流程、评测集，要持续沉淀为内部资产；
• 运行、治理、调优要尽早纳入架构，不要等上线后补；
• 对 Agent 自主权保持克制，按场景逐步放大；
• 用真实业务指标衡量 ROI，而不是只看演示效果。

Agent 的技术演进还会继续加速。越是这样，企业越需要分清哪些是会被基础设施吸收的通用能力，哪些是自己必须长期建设的业务能力。

“智能面积”这个概念的价值就在这里：它提醒企业不要只追横向的通用智能，也别忽视纵向的业务深度。真正可持续的 AI 生产力，通常出现在两者交汇的地方。