1. 当平台把底层能力吃干抹净Agent 产品还剩什么牌可打这两年做 Agent 产品的团队都有一个共同的体感底层能力正在以肉眼可见的速度被平台方收编。去年还要自己吭哧吭哧搭一套工具调用框架、写一堆 function calling 的胶水代码、处理各种流式输出的边界情况今年打开 Agents API 的文档一看工具调用、状态管理、多轮编排、文件读写、代码执行平台全给你包圆了。你辛辛苦苦写了三个月的编排层可能一次平台更新就被降维成一行配置。这个现象不是坏事但它逼着每一个做 Agent 产品的人回答一个很尖锐的问题当底层能力不再是壁垒你的产品到底在卖什么我见过太多团队在这个问题上翻车——他们花了大量精力去卷那些平台迟早会做的事比如更花哨的工具注册机制、更复杂的重试逻辑、更底层的 token 调度结果平台一升级这些工作全部归零。而真正该花力气的地方——领域知识、工作流设计、交互体验、结果可信度——反而被忽略了。这篇文章想聊的就是这件事。我会从 Agent 产品的架构分层讲起拆解哪些能力应该果断交给平台、哪些能力必须自己攥在手里然后重点讲清楚在底层被托管之后产品层还能构建哪些真正的护城河。涉及到的关键词包括 Agent、Agents API、Codex、Skills、MCP 这些当下最热的实践方向但重点不是介绍它们是什么而是讲清楚在真实项目里怎么用、怎么取舍、怎么避坑。适合正在做 Agent 产品、或者准备入局这个方向的开发者和产品负责人参考不管你是刚起步还是已经踩过一轮坑应该都能找到对你有用的部分。2. 先想清楚哪些能力该交出去哪些必须自己扛2.1 平台托管的能力边界在哪里要回答还要做什么得先搞清楚平台已经做了什么。以目前主流的 Agents API 为例它托管的能力大致可以分成四层。最底层是模型推理本身这个不用多说你不可能自己训一个能打的基座模型。往上一层是工具调用协议也就是模型怎么决定调用哪个工具、传什么参数、怎么处理返回结果这一层现在平台基本都标准化了你只需要按规范注册工具就行。再往上是编排与状态管理多轮对话的上下文维护、任务分解、子任务调度、失败重试这些平台也在快速补齐。最上面一层是执行环境代码沙箱、文件系统、网络访问平台提供的沙箱环境在安全性和稳定性上通常比自建的要好。我自己的判断标准很简单如果一个能力是通用的也就是所有 Agent 产品都需要、且实现方式大同小异那它迟早会被平台收编你就不要在这上面投入重兵。工具调用的重试逻辑、流式输出的解析、token 计数的统计这些都属于通用能力自己写除了增加维护成本没有任何收益。反过来如果一个能力是领域特定的也就是只有你的场景需要、且实现方式高度依赖业务理解那它就是你的地盘。这里有个很容易踩的坑很多团队会把通用能力的定制化封装误认为是自己的壁垒。比如你封装了一套特别好用的工具注册 DSL觉得这是核心竞争力但实际上平台只要提供一个差不多的接口你的 DSL 就失去了存在意义。判断标准是去掉这层封装用户能不能感知到差异如果用户感知不到那这层封装就是自嗨。2.2 自建能力的三个判断维度那到底哪些能力值得自己扛我总结下来有三个维度可以帮你做判断。第一个维度是领域知识的密度。你的产品在某个垂直场景里积累了多少别人没有的知识比如一个做法律合同审查的 Agent它背后那套合同条款的比对规则、风险点的识别逻辑、不同法域下的差异处理这些是平台不可能提供的因为平台要做通用通用就意味着它不会为某一个垂直场景做深度优化。这类领域知识往往以 Skills 的形式沉淀下来是产品最硬的壁垒。第二个维度是工作流的独特性。你的用户完成任务的方式是不是有特定的步骤和顺序比如一个做代码审查的 Agent它的工作流可能是先跑静态检查、再看 diff、然后对照团队规范逐条核对、最后生成带优先级的评论这个流程是你们团队在长期实践中打磨出来的换一个团队可能完全不一样。这种工作流的编排逻辑平台给不了你因为它不知道你的团队怎么干活。第三个维度是结果的可信度要求。有些场景对结果的准确性要求极高容不得模型胡说八道这时候你就需要在平台能力之上加一层校验和兜底机制。比如金融数据查询模型给出的数字必须经过二次核对比如医疗建议必须有明确的免责和转人工机制。这类可信度建设是产品能不能被用户信任的关键也是平台不会替你做的。2.3 一个实用的分层决策表为了让大家更直观地做判断我整理了一个分层决策表把常见的 Agent 能力按该不该自建分类。这个表是我在几个项目里反复验证过的你可以直接拿去对照自己的产品。能力类型具体例子建议归属判断理由模型推理基座模型调用、参数调优平台自建成本极高无差异化空间工具调用协议function calling、参数校验平台已标准化自建纯属重复劳动状态管理上下文维护、会话持久化平台为主通用需求平台实现更稳执行沙箱代码运行、文件读写平台安全性和隔离性平台更强领域知识行业规则、专业术语库自建平台无法覆盖垂直深度工作流编排特定任务的步骤设计自建高度依赖业务理解结果校验事实核对、格式约束自建可信度是产品生命线交互体验特定场景的 UI/UX自建直接面向用户差异化明显数据闭环用户反馈、效果追踪自建数据是长期资产这张表的核心逻辑是越靠近模型和基础设施的越交给平台越靠近用户和业务的越自己扛。你在表里的位置越靠下你的产品就越难被替代。3. 底层托管之后产品层的四个真实发力点3.1 用 Skills 把领域知识沉淀成可复用的资产平台把工具调用标准化之后一个直接的好处是你可以把精力从怎么让模型调用工具转移到模型该知道什么上。这就是 Skills 这个概念的价值所在。Skills 本质上是对领域知识的结构化封装它告诉 Agent 在特定场景下应该遵循什么规则、参考什么资料、按什么标准判断。我拿一个实际项目举例。我们做过一个面向前端团队的代码审查 Agent最初的做法是把审查规则写在一段超长的 system prompt 里结果模型经常顾此失彼规则一多就开始漏。后来改成 Skills 的方式把规则拆成几个独立的技能包一个管代码风格缩进、命名、注释规范一个管性能隐患大列表渲染、不必要的重渲染、内存泄漏风险一个管可访问性语义化标签、键盘导航、屏幕阅读器兼容。每个技能包有自己的触发条件和检查清单Agent 根据 diff 的内容决定加载哪些技能包。这个改造带来的效果非常明显。首先是准确率上去了因为每个技能包的规则更聚焦模型不容易混淆。其次是可维护性好了产品经理要加一条新规则只需要在对应的技能包里加一条不用去动那段越来越长的 prompt。最重要的是这些技能包变成了团队的资产——它们不依赖于某个特定的模型或平台换一个底层模型技能包照样能用。这里有个实操心得Skills 的粒度要控制好太粗了等于没拆太细了模型调用成本高。我的经验是一个技能包对应一类明确的判断任务规则数量控制在 5 到 15 条之间。少于 5 条说明拆得太细可以合并多于 15 条说明这个技能包承担了太多职责应该继续拆。另外每个技能包最好配几个正例和反例让模型对边界情况有更清晰的认知这比单纯写规则有效得多。3.2 用 MCP 打通外部系统但别把它当万能钥匙MCP 这两年热度很高它的价值在于提供了一套标准化的协议让 Agent 能够以统一的方式访问外部工具和数据源。以前你要接一个数据库、一个 API、一个文件系统每个都要写一套适配代码现在有了 MCP理论上只要对方提供了 MCP server你就能直接接上。但我在实际项目里发现很多人对 MCP 的期待过高了。MCP 解决的是连接问题它让 Agent 能访问到外部系统但它不解决理解问题。举个例子你通过 MCP 接上了一个项目管理工具Agent 能读到所有的任务和评论但它不一定知道哪些信息对当前任务重要、该怎么解读这些信息、遇到冲突时该信谁。这些还是需要你在产品层做设计。我的建议是把 MCP 当作数据通道而不是智能层。MCP 负责把数据拿进来你的 Skills 和工作流负责把数据用起来。具体做法上我会在 MCP 返回的原始数据之上加一层语义封装把原始字段映射成 Agent 容易理解的业务概念。比如项目管理工具返回的 status 字段可能是 in_progress、blocked、done 这些枚举值我会在封装层把它们翻译成正在进行中预计还需要两天、被阻塞了需要先解决依赖问题这样的自然语言描述模型处理起来会顺畅很多。还有一个坑要注意MCP server 的响应延迟和稳定性会直接影响 Agent 的体验。我遇到过 MCP server 偶尔超时导致整个 Agent 卡住的情况后来加了超时和降级机制——如果某个 MCP 调用超过 3 秒没返回就先跳过用缓存数据或者提示用户稍后重试不要让整个流程被一个慢接口拖死。3.3 工作流编排把怎么做变成产品的核心资产如果说 Skills 解决的是知道什么那工作流编排解决的就是怎么做。这是我认为在底层托管之后产品层最值得投入的方向。为什么因为工作流是高度场景化的平台不可能为每个垂直场景预设一套流程。而且工作流的设计直接决定了用户体验的好坏。同样一个任务流程设计得好用户觉得顺畅高效设计得差用户觉得绕来绕去还不如自己动手。我拿一个内容创作的 Agent 举例。最初的设计是用户输入主题 → 模型生成大纲 → 模型写正文 → 输出很直接但用户反馈说生成的内容太泛没有针对性。后来我们改成了多阶段的工作流第一阶段先做需求澄清Agent 主动问几个问题目标读者是谁、想要什么风格、有没有必须包含的点、字数要求第二阶段基于澄清结果生成大纲并让用户确认第三阶段才写正文写完后还有一个自检环节检查是否覆盖了用户提的所有要求。这个流程比原来长了但用户满意度反而高了因为最终产出的质量明显提升。这里的关键洞察是Agent 产品的工作流设计本质上是在自动化和可控性之间找平衡。全自动听起来很酷但在很多场景下用户并不放心把控制权完全交出去。适当增加确认节点、让用户参与关键决策反而能提升整体的信任度和满意度。当然确认节点也不能太多否则用户会觉得烦。我的经验是在一个完整任务流程里设置 1 到 2 个关键确认点比较合适通常放在方向性决策的位置比如大纲确认、方案选择而不是每个细节都问。3.4 结果可信度产品能不能活下来的底线前面三点讲的是怎么让产品更好用这一点讲的是怎么让产品能用。结果可信度是 Agent 产品的生命线尤其是在企业级场景里一个不可信的 Agent 还不如没有。可信度建设有几个层次。最基础的是格式约束确保输出符合预期的结构比如 JSON schema 校验、必填字段检查。这一层相对好做平台一般也提供了一些支持。往上一层是事实核对对于涉及具体数据、引用、计算的输出要有独立的验证机制。比如 Agent 说根据上季度财报营收增长了 15%这个 15% 必须能追溯到数据源不能是模型编的。再往上是逻辑一致性检查确保 Agent 的多步推理没有自相矛盾的地方。我在项目里常用的一个做法是双通道验证让 Agent 用两种不同的方式得出同一个结论如果两个结果一致可信度就高如果不一致就标记出来让用户判断或者触发人工复核。比如做数据提取时一路用模型直接抽取一路用规则引擎匹配两边结果比对。这个做法会增加一些成本但在关键场景下非常值得。还有一个容易被忽略的点是不确定性表达。很多 Agent 产品为了显得智能不管有没有把握都用很肯定的语气回答这其实是在透支用户信任。更好的做法是让 Agent 能够表达自己的确定程度比如根据现有信息我比较确定是 X和我不太确定可能是 X 也可能是 Y建议你核实一下。这种诚实的表达短期看好像不够智能但长期看能建立更稳固的信任关系。4. 从零搭一个 Agent 产品的实操路径4.1 技术选型别一上来就追求大而全讲完理念来说点具体的。如果你现在要从零搭一个 Agent 产品技术选型怎么做我的建议是先用平台能力快速跑通再逐步替换需要自建的部分。起步阶段直接用 Agents API 提供的能力把核心流程跑通。这个阶段的目标是验证产品逻辑不是追求技术先进性。工具调用用平台的标准接口状态管理用平台提供的会话机制执行环境用平台的沙箱。你可能觉得这样没有技术含量但恰恰是这个阶段能帮你快速发现产品层面的问题——用户到底需要什么、流程哪里不顺、哪些环节容易出错。跑通之后开始识别哪些地方平台能力不够用。通常是这几类领域知识需要更结构化的管理引入 Skills、外部系统需要更灵活的对接引入 MCP、工作流需要更精细的控制自建编排层、结果需要更严格的校验自建验证层。每识别出一个就针对性地补一块不要一次性全上。关于 Codex 这类工具的使用我的经验是把它当作加速器而不是替代品。它能帮你快速生成一些样板代码、处理一些重复性的编码任务但核心的架构决策、领域逻辑设计还是得自己来。我见过有人试图让 Codex 直接生成整个 Agent 产品结果出来的东西能跑但没法用因为缺少对业务的理解。4.2 一个最小可用的 Agent 产品骨架下面给一个我常用的 Agent 产品骨架用伪代码表示你可以根据自己的技术栈翻译成具体实现。# 产品层核心结构伪代码示意 class AgentProduct: def __init__(self): self.skills SkillRegistry() # 领域知识自建 self.workflow WorkflowEngine() # 工作流编排自建 self.validator ResultValidator() # 结果校验自建 self.platform AgentsAPI() # 底层能力平台托管 def handle_task(self, user_input): # 1. 需求理解与澄清 clarified self.workflow.clarify(user_input) # 2. 加载相关技能 relevant_skills self.skills.match(clarified) # 3. 执行工作流 result self.workflow.execute( inputclarified, skillsrelevant_skills, toolsself.platform.get_tools() ) # 4. 结果校验 validated self.validator.check(result) # 5. 返回附带可信度标记 return validated这个骨架的关键在于平台能力被封装在self.platform里产品自己的逻辑在 skills、workflow、validator 三个模块。这样设计的好处是当平台能力升级或者你想换一个平台时只需要改self.platform这一层产品逻辑不受影响。4.3 迭代节奏小步快跑数据驱动Agent 产品的迭代和传统软件不太一样因为模型的行为有一定的不可预测性你很难在上线前把所有情况都测到。所以我的建议是小步快跑用真实数据驱动迭代。具体做法是第一版只覆盖最核心的场景哪怕只支持一种任务类型。上线后重点收集两类数据一类是成功案例看看 Agent 在什么情况下表现好把这些模式固化下来一类是失败案例分析失败的原因是知识不够、流程不对、还是校验缺失针对性地补。我一般会建一个案例库把典型的成功和失败案例都存下来每个案例标注清楚输入、期望输出、实际输出、问题分类。这个库积累到几十个案例之后你就能看出明显的模式了。比如你可能会发现Agent 在处理多条件筛选类任务时特别容易出错那就可以专门为这类任务设计一个技能包或者校验规则。这里有个经验不要试图一次性解决所有问题优先解决高频问题。Agent 产品早期一定有很多不完美的地方但用户最在意的是那些高频场景能不能稳定工作。把 80% 的常见情况处理好比追求 100% 的覆盖率更实际。5. 那些踩过的坑和对应的解法5.1 常见问题速查表做 Agent 产品这两年踩过的坑不少我整理了一个速查表都是真实遇到过的问题和验证过的解法。问题现象可能原因排查方向解法Agent 频繁调用同一个工具工具描述不清晰或结果不符合预期检查工具描述和返回格式优化工具描述确保返回结果结构化多轮对话后忘记早期信息上下文窗口溢出或摘要丢失关键信息检查上下文管理策略引入关键信息提取单独维护输出格式不稳定约束不够明确或模型理解偏差检查 prompt 和校验逻辑加 schema 校验失败时重试响应速度慢工具调用串行或 MCP 超时分析各环节耗时并行化独立调用加超时降级结果看似合理但实际错误缺少事实核对抽查输出的事实准确性引入双通道验证用户不知道 Agent 在干什么缺少过程反馈观察用户困惑点增加中间状态提示换模型后效果大幅波动过度依赖特定模型特性检查 prompt 和技能包的模型耦合度抽象模型无关的接口层5.2 三个最值得说的避坑经验第一个坑是过度依赖模型的自觉。早期我总觉得只要 prompt 写得好模型就会按预期行事。实际做下来发现模型在长流程、多步骤的任务里很容易跑偏或者偷懒。后来我的做法是关键节点一定要有程序化的检查不能全靠模型自觉。比如要求模型输出 JSON那就一定要有 JSON 解析和 schema 校验解析失败就重试或者报错不要指望模型每次都输出合法 JSON。第二个坑是技能包写得太多太杂。一开始觉得技能越多越强大结果模型在加载技能时经常选错或者加载了不相关的技能导致输出跑偏。后来学乖了技能包要精不要多每个技能包要有明确的适用边界。而且我加了一个技能选择的中间步骤让模型先判断当前任务需要哪些技能再加载比一股脑全加载效果好很多。第三个坑是忽视冷启动阶段的数据积累。Agent 产品很依赖数据来优化但冷启动阶段没有数据怎么办我的做法是人工构造一批种子案例覆盖主要的场景类型用这批案例来做初始的 prompt 调优和技能包设计。这批种子案例不需要很多二三十个高质量的就行但一定要覆盖到各种边界情况。等真实用户数据进来之后再逐步替换和补充。5.3 关于 Agent 安全的一点实践Agent 安全是个大话题我这里只讲一个最实际的点权限控制。Agent 能调用工具、能访问数据如果权限控制不好可能会造成意想不到的后果。我的做法是遵循最小权限原则Agent 只拥有完成当前任务所必需的权限任务完成后权限回收。对于敏感操作比如删除数据、发送消息、执行支付一定要有二次确认机制不能让 Agent 自主决定。另外对于 Agent 生成的内容尤其是要对外发布或者影响真实系统的我建议加一道人工审核或者自动化的安全检查。这不是不信任 Agent而是对用户负责。我在项目里见过 Agent 因为理解偏差生成了不恰当的回复如果没有审核机制就直接发出去后果会很严重。6. 往后看Agent 产品的差异化会越来越集中在软能力上写到这里我想分享一个越来越强烈的感受。随着平台把底层能力越做越完善Agent 产品之间的竞争会越来越集中在那些软能力上——不是技术有多先进而是对场景的理解有多深、对用户需求的把握有多准、对结果质量的把控有多严。我见过一些技术很炫的 Agent 产品用了最新的框架、最复杂的架构但用户用了一次就不想再用因为解决不了实际问题。也见过一些技术上看起来很朴素的产品就是把某个垂直场景的需求吃得很透流程设计得很顺结果用户粘性非常高。这个对比让我意识到在 Agent 这个领域技术实现的重要性在下降产品思维的重要性在上升。所以如果你正在做 Agent 产品我的建议是把更多时间花在理解用户、打磨流程、积累领域知识上而不是追逐最新的技术概念。平台会帮你解决底层的问题你要解决的是平台解决不了的问题。那些看起来不酷的工作——整理领域规则、设计确认节点、建立校验机制、收集用户反馈——恰恰是产品真正的护城河。最后分享一个我一直在用的小方法每当你觉得某个功能平台迟早会做的时候就把它标记出来然后问自己如果平台明天就做了这个功能我的产品还剩下什么价值。如果答案是什么都不剩那说明你的产品还没有找到真正的立足点需要重新思考。如果答案是我还有一堆平台做不了的东西那恭喜你你走在正确的路上。