企业官网建设流程全解析

1. 当模型和运行时都被平台收编，Agent 产品的价值锚点在哪

过去一年我参与过三个 Agent 产品的从零搭建，也帮朋友复盘过五六个中途夭折的项目。一个反复出现的现象是：团队花了大量时间在"怎么让模型稳定输出 JSON""怎么把工具调用串起来""怎么管理多轮上下文"这些事上，结果平台方一次 API 升级，这些工作有一大半直接作废。OpenAI 的 Agents API、Codex 这类命令行编码 Agent、以及围绕 Skills 和 MCP 建立起来的工具生态，正在把过去需要自己写几百行胶水代码才能做到的事，变成一次配置或一次声明。

这就引出一个很现实的问题：底层能力交给平台以后，Agent 产品还要做什么？

如果你正在做 Agent 方向的产品，或者准备入局，这篇文章想聊的不是"怎么调 API"，而是当模型推理、工具编排、上下文管理、甚至代码执行沙箱都被平台标准化之后，一个 Agent 产品真正该把精力放在哪里。我会结合 Agents API、Codex、Skills、MCP 这几个当前最热的技术点，拆解哪些能力正在被平台吃掉、哪些能力平台吃不掉、以及产品层该怎么重新定位自己的护城河。适合已经动手做过 Agent demo、但发现"能跑通"和"能上线"之间隔着一条鸿沟的开发者，也适合正在评估 Agent 产品方向的技术负责人。

先说结论：平台收编的是通用能力，收编不了的是领域知识、任务编排策略、结果可信度和用户信任。这四件事，才是 Agent 产品接下来的主战场。

2. 平台到底吃掉了哪些活：从 Agents API 和 Codex 说起

要搞清楚"还要做什么"，得先搞清楚"已经不用做什么了"。很多人对平台能力的边界其实没有清晰认知，要么低估了平台、重复造轮子，要么高估了平台、把不该交的东西也交出去了。

2.1 Agents API 把工具调用和状态管理标准化了

在 Agents API 出现之前，做一个能调用多个工具的 Agent，你得自己实现一套循环：模型输出工具调用意图 → 解析 → 执行工具 → 把结果塞回上下文 → 再次请求模型 → 判断是否结束。这套循环看着简单，实际写起来全是坑：工具调用格式解析失败怎么办、并行调用怎么处理、超时怎么重试、上下文超长怎么截断。

Agents API 这类平台能力的核心价值，就是把这套循环变成了平台侧的责任。你只需要声明有哪些工具、每个工具的输入输出 schema，剩下的编排逻辑平台帮你跑。这意味着过去一个 Agent 框架里最核心的"调度器"部分，价值被大幅稀释了。

我实测下来的感受是：如果你的 Agent 只涉及标准的"请求-工具-响应"模式，自己写调度器已经几乎没有意义。省下来的时间应该投到工具本身的质量和任务策略上，而不是调度逻辑上。

2.2 Codex 这类编码 Agent 把"执行环境"也接管了

Codex 这类命令行编码 Agent 更狠一点，它不只是编排工具，而是直接提供了一个带文件系统、能执行命令、能读写代码的运行环境。你给它一个任务，它会自己决定读哪些文件、跑什么命令、改哪几行代码。

这背后的意义是：代码执行沙箱、文件操作、命令执行这些过去需要自己搭的基础设施，平台直接给你了。以前做一个"能自动改代码"的 Agent，光是安全地执行用户代码这一件事就够一个团队喝一壶，现在这部分被平台标准化了。

但这里有个容易被忽略的细节：Codex 这类工具的能力边界是"通用编码任务"。它能改代码，但它不知道你的业务规则、不知道你们团队的代码规范、不知道哪个模块动不得。这些恰恰是产品层要补的。

2.3 Skills 和 MCP：工具生态的"即插即用"

Skills 和 MCP 解决的是另一个维度的问题：工具怎么接入。MCP 定义了一套标准协议，让 Agent 能以统一的方式连接外部工具和数据源；Skills 则更像是把一组能力打包成可复用的模块，Agent 按需加载。

这两个东西的价值在于，它们把"工具接入"从每个项目各写各的，变成了生态级的复用。你想让 Agent 能操作数据库、能读 Figma 设计稿、能查内部文档，只要有对应的 MCP server 或 Skill，接上就能用。

下面这张表可以帮你快速判断，哪些能力已经可以放心交给平台：

看懂这张表，基本就理解了"平台吃掉什么、留下什么"的分界线。接下来逐层拆解产品层该做的事。

3. 领域知识：平台永远给不了的那部分

平台能给你通用的推理能力和工具编排，但它不知道你的业务。这是 Agent 产品最扎实的一块护城河，也是最容易被低估的一块。

3.1 通用 Agent 和领域 Agent 的分水岭

我见过太多团队做出一个"什么都能聊、什么都能干一点"的通用 Agent，然后发现用户用完一次就不来了。原因很简单：通用能力平台自己就能提供，用户为什么要用你的？

真正能留住用户的，是那些"平台做不了、只有你能做"的事。比如一个面向电商运营的 Agent，它需要知道平台的促销规则、知道哪些品类不能打折、知道库存和销量的联动逻辑。这些知识不在任何公开模型里，只能靠你在产品层沉淀。

领域知识通常分三层：

• 显性规则：能写成文档的业务规则，比如"退款超过 7 天需要人工审核"。这类知识相对好处理，做成 Skill 或提示词注入即可。
• 隐性经验：老员工脑子里那些"遇到这种情况一般这么处理"的判断，比如"这个客户历史投诉多，回复要格外谨慎"。这类知识需要靠案例积累和反馈迭代。
• 动态上下文：实时变化的业务数据，比如当前库存、当前活动、当前工单状态。这类知识要靠 MCP 连接实时数据源。

三层里，显性规则最容易做，也最容易被复制；隐性经验和动态上下文才是真正拉开差距的地方。

3.2 把领域知识做成 Skill 而不是塞进提示词

一个常见的错误做法是把所有领域知识都堆进系统提示词里。提示词越写越长，模型注意力被稀释，效果反而下降，而且改一处要动全身。

更合理的做法是把领域知识拆成独立的 Skill。每个 Skill 负责一类任务，自带该任务需要的规则、示例和工具。Agent 在处理具体任务时按需加载对应的 Skill，而不是一次性把所有知识都塞进上下文。

这样做有几个好处：一是上下文更干净，模型在具体任务上的表现更稳；二是知识可以独立迭代，改一个 Skill 不影响其他；三是 Skill 可以复用，同一个"退款处理"Skill 能用在多个 Agent 场景里。

提示：拆 Skill 的粒度建议按"任务"而不是按"知识类型"。一个 Skill 对应一类用户能说清楚的任务，比如"处理退款申请"，而不是"退款规则集合"。前者模型更容易判断何时加载，后者容易变成又一个知识库。

3.3 领域知识的持续更新机制

领域知识不是一次写完就完事的。业务在变、规则在变、用户在变，Agent 的知识也得跟着变。

我踩过的一个坑是：早期把领域知识硬编码在代码里，结果业务规则一改就要发版，迭代速度完全跟不上。后来改成配置化，规则存在数据库里，运营可以自己改，情况才好起来。

更进一步的思路是让 Agent 自己参与知识更新。比如记录每次任务的处理结果和用户反馈，定期让模型总结"哪些情况处理得好、哪些处理得差"，把差的部分提炼成新的规则或示例，补充进对应的 Skill。这套机制跑起来之后，知识库的更新就从"人工维护"变成了"半自动进化"。

4. 任务编排策略：从"能调用工具"到"知道先干什么"

平台给了你工具调用的能力，但没告诉你什么时候该调用哪个工具、按什么顺序调用、失败了怎么办。这些策略层面的东西，是 Agent 产品第二个核心战场。

4.1 为什么工具编排策略不能交给平台

Agents API 能帮你执行工具调用，但它不知道你的业务优先级。举个例子：用户说"帮我处理一下这个订单的问题"，平台层面的 Agent 可能会去查订单状态、查物流、查支付记录，但它不知道在你的业务里，应该先确认订单是否在售后期内，因为不在售后期的订单根本不用往下查。

这种"先判断什么、再执行什么"的策略，是领域特有的，平台给不了。它需要你把业务逻辑翻译成 Agent 能执行的决策树或优先级规则。

4.2 用"决策前置"减少无效工具调用

一个实用的策略是决策前置：在真正调用工具之前，先用一轮轻量的判断确定任务类型和优先级，再决定调用哪些工具。

具体做法是让 Agent 先做一次"任务分类"，把用户请求归到预定义的几类任务里，每类任务对应一套工具调用流程。这样能避免 Agent 漫无目的地试各种工具，既省 token 又提准确率。

我实测过一个客服 Agent，加了任务分类这一步之后，平均工具调用次数从 6.3 次降到 3.1 次，任务完成率反而提升了。原因很简单：分类之后 Agent 目标更明确，不会在无关工具上浪费轮次。

4.3 失败重试和降级策略的设计

工具调用失败是常态，不是异常。网络抖动、接口限流、数据缺失，任何一种都会让工具调用失败。平台通常提供基础的重试机制，但业务层面的降级策略得你自己设计。

我一般会按这个优先级设计降级：

1. 重试：瞬时故障，直接重试，但要设上限，避免死循环。
2. 换路径：主工具不可用时，切换到备用工具或备用数据源。
3. 降级回答：实在拿不到数据，就基于已有信息给出部分回答，并明确告诉用户哪部分没拿到。
4. 转人工：关键任务失败时，果断转人工，别硬撑。

这里有个经验：降级策略要提前设计，不能等出问题再补。我见过一个 Agent 因为没设计降级，某个工具挂了之后整个流程卡死，用户等了三分钟没响应直接关掉了。

5. 结果可信度：Agent 产品能不能上线的生死线

如果说领域知识和编排策略决定 Agent 好不好用，那结果可信度决定 Agent 能不能用。一个偶尔胡说八道的 Agent，用户用两次就不敢用了。

5.1 Agent 幻觉在业务场景里的具体表现

通用聊天场景里，模型说错一句话用户可能一笑而过。但在业务场景里，幻觉的代价是实打实的。我整理过几类高频幻觉：

• 编造数据：明明没查到订单，却说"您的订单已发货"。
• 错误归因：把 A 规则套到 B 场景上，给出看似合理实则错误的建议。
• 过度承诺：用户问能不能退款，Agent 直接说"可以"，但实际不符合退款条件。
• 遗漏关键约束：处理任务时漏掉了某个必须满足的前置条件。

这几类里，过度承诺和遗漏约束最危险，因为它们直接导致业务损失。

5.2 用"证据链"约束 Agent 的输出

一个有效的做法是要求 Agent 的每个关键结论都必须有证据支撑。具体来说，Agent 在给出结论时，要同时给出这个结论基于哪些工具返回的数据、哪些规则。

实现上可以这样做：在工具返回结果时，给每条数据打上来源标记；在生成最终回答时，要求模型引用这些来源。如果某个结论找不到对应的数据来源，就标记为"不确定"，要么不输出，要么明确告诉用户这是推测。

这套机制不能 100% 消除幻觉，但能大幅降低"凭空编造"的概率，而且让问题变得可追溯——出了错能定位到是哪一步的数据或规则出了问题。

5.3 关键动作的二次确认机制

对于有实际后果的动作，比如提交退款、发送消息、修改数据，一定要加二次确认。这里的确认不是简单地弹个框让用户点"确定"，而是让 Agent 把"我准备做什么、基于什么信息、会产生什么后果"讲清楚，用户确认后再执行。

我见过一个做得不错的实现：Agent 在执行关键动作前，会生成一段"执行预览"，列出即将执行的操作、涉及的数据、预期结果，用户确认后才真正执行。这个设计把很多潜在的错误挡在了执行之前。

注意：二次确认会增加交互轮次，影响体验。建议只对"不可逆"或"高代价"的动作加确认，普通查询类操作不要加，否则用户会烦。

6. 用户信任：比技术更难建立、更容易摧毁的东西

技术能力可以靠堆人力堆出来，用户信任不行。它建立得慢，摧毁得快，而且一旦失去很难挽回。

6.1 信任来自"可预期"而不是"聪明"

很多团队追求让 Agent 显得"聪明"，回答得花哨、能力强。但用户真正需要的是可预期：我知道这个 Agent 能做什么、不能做什么、遇到问题会怎么处理。

一个可预期的 Agent，即使能力有限，用户也愿意用；一个能力很强但行为不可预期的 Agent，用户不敢把重要任务交给它。

建立可预期性的几个做法：明确告知能力边界、对不确定的事情明确说"不确定"、行为模式保持一致（同样的输入给同样的处理路径）、出错时给出清晰的解释而不是含糊其辞。

6.2 让用户能"看见"Agent 在做什么

黑盒是信任的天敌。用户不知道 Agent 在干什么，就会焦虑、就会不信任。

解决办法是适度透明。不是把所有内部推理都暴露出来（那会信息过载），而是把关键节点展示给用户：正在查什么、查到了什么、接下来准备做什么。这种"进度可见"的设计能显著提升用户的掌控感。

我在一个项目里做过对比测试：加了执行进度展示的版本，用户中途放弃率比不加的版本低了将近四成。用户不是不能等，是不能接受"不知道在等什么"。

6.3 错误处理方式决定信任的存亡

Agent 一定会出错，关键是怎么处理错误。我总结了几条原则：

• 主动承认：错了就直说，别试图掩盖或含糊过去。
• 解释原因：告诉用户为什么出错，是数据问题、规则问题还是理解问题。
• 给出补救：提供替代方案或转人工，别让用户卡在那里。
• 记录反馈：把错误案例记下来，用于后续优化。

最忌讳的是"假装没错"。用户发现 Agent 给了错误信息还不承认，信任瞬间归零，而且很难再建立起来。

7. 一个可落地的 Agent 产品分层架构

聊了这么多"要做什么"，最后给一个我实际用过的分层架构，帮你把上面的思路落地。

7.1 四层架构的职责划分

我把 Agent 产品分成四层：

• 平台层：模型、Agents API、Codex 类执行环境、MCP 协议。这层直接用平台能力，不自己造。
• 能力层：领域 Skill、工具封装、数据连接。这层是产品自己的资产，需要持续投入。
• 策略层：任务分类、编排流程、降级策略、可信度校验。这层是产品的"大脑"，决定 Agent 的行为质量。
• 交互层：进度展示、二次确认、错误处理、反馈收集。这层直接决定用户体验和信任。

四层里，平台层是买来的，能力层和策略层是自建的，交互层是打磨出来的。资源应该重点投在后三层。

7.2 各层的迭代节奏

不同层的迭代节奏不一样，别用同一套流程管：

策略层迭代最频繁，因为它直接对效果负责。我一般会每周做一次 badcase 复盘，把问题归类到策略层的具体环节，然后针对性调整。

7.3 从 demo 到上线的关键检查项

最后给一份上线前的检查清单，都是踩过坑总结出来的：

• 领域知识是否覆盖了主要业务场景，边界情况有没有处理？
• 工具调用失败时，降级路径是否都验证过？
• 关键结论是否有证据支撑，幻觉率是否在可接受范围？
• 不可逆动作是否都有二次确认？
• 出错时用户能否得到清晰解释和补救方案？
• 是否有机制收集用户反馈并回流到策略层？

这份清单里的每一项，都是我在实际项目里因为没做好而付出过代价的。Agent 产品从 demo 到上线，难的从来不是技术，而是这些看起来琐碎但决定成败的细节。

平台把底层能力收编，对 Agent 产品来说不是威胁，而是解放。它让你不用再重复造轮子，可以把精力投到真正创造差异的地方——领域知识、编排策略、结果可信度和用户信任。这四件事，平台做不了，也做不好，因为它们需要的是对具体业务的理解和持续的运营投入，而不是通用的技术能力。想清楚这一点，Agent 产品的方向其实比过去更清晰了。