1. 当平台把地基打好了Agent 产品的真正战场在哪里这两年做 Agent 相关产品的团队几乎都经历过一个心态上的过山车。2023 年大家还在手搓 ReAct 循环、自己写 function calling 的解析器、为了一个稳定的工具调用格式调半天 prompt到了 2024 年下半年OpenAI 把 Agents API、Codex、Skills、MCP 这一套东西陆续摆上台面很多原本需要自己啃的底层活儿——工具注册、上下文管理、多轮编排、代码执行沙箱——平台直接给你包好了。于是问题就来了底层能力交给平台以后Agent 产品还要做什么这个问题不是学术讨论是很多团队在排期会上真真切切吵过的事。我身边就有做垂直 Agent 的朋友去年花了三个月自研了一套工具调度框架结果 OpenAI 的 Agents API 一出来那套框架的价值瞬间被削掉一大半。他当时的原话是感觉白干了。但半年过去他的产品反而活得比之前好因为他想明白了一件事平台负责的是能不能跑起来产品负责的是跑起来之后对谁有用。这篇文章我想聊的就是这件事。适合谁看如果你正在做 Agent 产品、正在纠结要不要自研底层、或者刚接触 Codex、Skills、MCP 这些概念但还没想清楚它们在产品里扮演什么角色那这篇应该能帮你省下不少试错时间。我会从架构分层、核心能力拆解、实操落地、常见坑四个角度把平台之上还能做什么这件事讲透。核心关键词会自然穿插在各个环节里不堆砌只讲我实际踩过和验证过的东西。先说结论方向平台把通用能力商品化之后Agent 产品的差异化只能来自三处——领域知识的深度、工具生态的独特性、以及交互体验的最后一公里。下面逐层拆。2. 先搞清楚平台到底给了什么你才知道自己该守什么2.1 Agents API、Codex、Skills、MCP 各自解决的是哪一层问题很多人把这几样东西混在一起谈其实它们处在完全不同的抽象层。我用一个盖房子的类比来说明Agents API 是毛坯房的水电煤Codex 是自带的一个全能装修队Skills 是你自己买的家具MCP 是连接外部世界的门窗管道。搞混了层级就会做出用 Skills 去干 MCP 的活这种别扭事。能力抽象层解决的核心问题你还需要自己做的Agents API编排层多轮对话、工具调用循环、状态管理业务逻辑、领域 prompt、评估体系Codex执行层代码生成、命令行操作、文件读写权限边界、沙箱策略、结果校验Skills能力层封装可复用的专项技能领域技能设计、触发条件、版本管理MCP连接层标准化对接外部工具与数据源服务端实现、鉴权、数据脱敏看这张表就明白了平台把编排层和执行层这两块最重、最通用的活儿接走了。以前你要自己实现一个稳定的 agent loop处理工具调用的异常、重试、超时、上下文裁剪现在 Agents API 帮你兜底。以前你要自己搭代码执行环境现在 Codex 直接给你一个能跑命令的 agent。但注意能力层和连接层平台只给了标准没给内容。Skills 是空壳你得往里填领域知识MCP 是协议你得自己实现服务端。这两块恰恰是产品差异化的主战场。2.2 为什么底层交给平台是必然而不是偷懒有些工程师会有一种执念觉得用平台的东西就是不够硬核。我理解这种心态但从产品角度讲自研底层在 2024 年之后基本是负收益。原因有三第一通用能力的边际成本趋近于零。你花三个月做的工具调度平台一次更新就覆盖了而且人家处理的长尾 case 比你多几个数量级。你自研的稳定性永远追不上。第二底层不是护城河是负债。底层代码要维护、要跟着模型升级、要处理各种边界。这些投入不产生用户价值只产生能跑这个及格线。把资源砸在这里等于把弹药浪费在别人已经建好的城墙上。第三平台的抽象会持续上移。今天它给你 Agents API明天可能给你更上层的编排 DSL。你越是贴着底层自研越容易被下一次抽象升级冲垮。反过来你越是把价值放在领域知识和工具生态上平台的升级对你越是利好——因为你的东西跑在更稳的地基上了。我那个朋友后来复盘说得很到位我原来以为我在做 Agent 框架其实我在做 Agent 框架的临时补丁。这句话值得每个还在纠结要不要自研底层的团队贴在墙上。2.3 一个判断标准什么该交给平台什么必须自己攥着我给一个实操中很好用的判断标准叫**通用性测试**如果一件事任何做 Agent 的团队都需要做且做法大同小异那就交给平台如果一件事只有你这个领域才需要或者不同团队做法差异巨大那就自己攥着。按这个标准过一遍工具调用循环、重试、超时 → 通用交给平台上下文窗口管理、历史裁剪 → 通用交给平台代码执行沙箱 → 通用交给 Codex领域知识库的构建与检索 → 专属自己做特定行业工具的 MCP 服务端 → 专属自己做面向具体用户的交互流程 → 专属自己做评估体系与质量红线 → 专属自己做这个标准能帮你快速划清边界避免在错误的地方投入。下面几节就展开讲自己攥着的那部分具体怎么做。3. 平台之上Agent 产品的三个真实差异化方向3.1 领域知识Skills 不是写 prompt是沉淀可复用的判断力很多人第一次接触 Skills会把它理解成高级一点的 prompt 模板。这个理解会让你把 Skills 做废。我见过太多团队把一段系统提示词塞进 Skill 里就完事结果发现效果和直接写 prompt 没区别还多了一层维护成本。Skills 的真正价值在于封装判断力而不是知识。知识模型本身就有判断力才是稀缺的。举个例子一个做财报分析的 Agent你写请分析这份财报是知识层面的指令模型自己会但如果你封装一个 Skill里面写清楚当毛利率环比下降超过 5 个百分点时必须交叉验证应收账款周转率若同时恶化则标记为高风险信号这就是判断力。这种判断力来自领域专家模型不会自己长出来。我实操下来一个好的 Skill 应该包含四个部分触发条件什么情况下该用这个 Skill写得越具体越好避免误触发执行步骤分步骤的操作指引每步说清楚输入输出判断规则领域专家才知道的 if-then 规则这是核心输出格式结构化输出方便下游消费提示Skill 的触发条件不要写得太宽泛。我踩过的坑是写了个处理用户关于数据的任何问题的 Skill结果它把大量无关请求都吸进来了反而干扰了主流程。触发条件要窄宁可多写几个 Skill。3.2 工具生态MCP 服务端才是你真正的资产如果说 Skills 是软实力那 MCP 服务端就是硬资产。MCP 这个协议本身是标准谁都能实现但你对接的那些外部系统、你封装的那些行业工具是别人抄不走的。我举个具体场景。假设你做的是工业设计领域的 Agent你要对接 Altium Designer 这类 EDA 工具。市面上通用的 MCP 服务端不会帮你做这件事因为太垂直了。但如果你自己实现了一个 MCP 服务端能让 Agent 直接读取原理图、查询元件库、甚至生成网表那这个能力就是你的护城河。别人要用要么自己重做一遍要么用你的。这里有个关键认知MCP 的价值不在协议在服务端的覆盖广度与深度。协议是公开的服务端是你一行行写出来的。我建议团队把 MCP 服务端当成核心资产来经营具体做法优先对接那些数据出不来的系统比如本地设计工具、内部 ERP、行业专用软件每个服务端都要做鉴权和数据脱敏这是上线的前提服务端的接口设计要稳定因为 Agent 会依赖它频繁改接口等于自断手脚做好版本管理MCP 服务端和 Agent 主流程要能独立升级3.3 交互体验最后一公里决定用户留不留平台把能力做完了但用户不会直接和能力对话用户和你的产品对话。这最后一公里的体验平台管不了因为平台不知道你的用户是谁、在什么场景下用、期待什么样的反馈。我观察到一个现象很多 Agent 产品在 demo 阶段惊艳上线后留存很差。原因往往不是能力不行而是交互没打磨。比如 Agent 执行一个长任务中间没有任何进度反馈用户盯着转圈等了 30 秒就关了比如 Agent 出错了只给一句执行失败用户完全不知道下一步该干嘛。这些细节平台不会帮你做因为它们是产品层的。我总结了几条实操经验长任务必须有中间态反馈哪怕只是正在查询第 3 个数据源也比干等强错误信息要可操作告诉用户哪一步失败了、可能的原因、建议怎么做而不是抛一个错误码关键决策点要让用户参与比如 Agent 要执行一个不可逆操作前必须确认结果要可追溯用户能回看 Agent 每一步做了什么、依据是什么这三块——领域知识、工具生态、交互体验——就是平台之上 Agent 产品的全部战场。下面进入实操环节。4. 从零搭一个平台之上的 Agent 产品完整实操4.1 环境准备与 Codex 接入的实操细节先讲环境。假设你已经决定用平台的 Agents API 做编排、用 Codex 做代码执行。Codex 的接入是很多人的第一道坎我按实际流程走一遍。Codex 本质是一个命令行 coding agent安装方式通常是 npm 包。在 Windows 上安装时我遇到过missing optional dependency openai/codex-win32-x64这类报错原因是可选依赖没装上。解决办法是显式重装npm install -g openai/codex # 如果报可选依赖缺失 npm install -g openai/codex --force安装完之后是登录。Codex 支持用 ChatGPT 账号登录走的是浏览器授权流程。这一步在国内网络环境下可能会卡我的经验是提前把网络环境准备好授权回调那一下不能断。注意Codex 的登录态是有有效期的长期跑的服务要处理好重新授权的逻辑别等到线上挂了才发现 token 过期。接入 Agents API 相对简单拿到 API key 之后核心是配置好工具列表和系统指令。这里有个容易忽略的点API key 的权限要最小化。不要用一个全权限的 key 跑所有 Agent按 Agent 的职责分配不同权限的 key出问题时影响面可控。4.2 用 Skills 封装领域判断力的完整示例光说概念太虚我给一个完整的 Skill 结构示例。假设做的是合同审查 Agent要封装一个风险条款识别的 Skill# Skill: 合同风险条款识别 ## 触发条件 当用户上传合同文件且请求涉及审查风险条款分析时触发。 ## 执行步骤 1. 解析合同文本按条款切分 2. 对每个条款匹配风险规则库 3. 对命中规则的条款提取原文并标注风险等级 4. 汇总输出风险清单 ## 判断规则 - 违约金比例超过合同总额 30%高风险 - 付款周期超过 90 天且无担保中风险 - 争议解决地不在双方注册地中风险 - 单方解除权无对等条款高风险 ## 输出格式 | 条款位置 | 原文摘录 | 风险等级 | 依据规则 |这个 Skill 的核心不是那几行步骤而是判断规则那部分。这些规则来自法务专家的经验模型自己不会知道违约金超过 30% 算高。这就是领域知识的价值。实操中我建议把规则库单独维护不要硬编码在 Skill 里。因为规则会变硬编码意味着每次改规则都要改 Skill、重新测试、重新发布。把规则抽成配置Skill 只负责读取规则并应用维护成本会低很多。4.3 MCP 服务端的实现要点与鉴权设计MCP 服务端是重头戏。我用一个对接内部知识库的 MCP 服务端为例讲清楚实现要点。MCP 服务端的核心是暴露一组工具给 Agent 调用。以查询知识库为例工具定义大概长这样{ name: query_knowledge_base, description: 查询内部知识库返回相关文档片段, inputSchema: { type: object, properties: { query: { type: string, description: 查询语句 }, top_k: { type: integer, default: 5 } }, required: [query] } }实现上有三个关键点第一鉴权必须做在服务端不能靠 Agent 自觉。Agent 调用工具时携带的凭证要校验校验不过直接拒绝。我见过有团队把鉴权逻辑写在 prompt 里让模型判断这是灾难性的模型可以被诱导绕过。第二返回数据要脱敏。知识库里可能有敏感信息返回给 Agent 之前要过滤。脱敏规则要可配置不同 Agent 看到的字段可以不同。第三接口要幂等。Agent 可能因为重试机制重复调用同一个工具如果你的工具是写操作重复调用会出问题。读操作天然幂等写操作要加去重逻辑。提示MCP 服务端的日志要打全但日志里不能有敏感数据。我一般记录谁在什么时候调用了哪个工具、参数摘要、返回条数不记录具体内容。4.4 把三者串起来一个完整的请求链路现在把 Skills、MCP、Agents API 串起来看一个完整链路。用户上传一份合同请求审查Agents API 接收请求加载系统指令和可用工具列表模型判断需要调用合同风险条款识别 SkillSkill 执行过程中需要查询内部合规规则库触发 MCP 工具调用MCP 服务端校验鉴权、查询、脱敏、返回Skill 结合规则库结果应用判断规则生成风险清单Agents API 把结果返回给用户附带可追溯的执行记录这条链路里平台负责的是第 1 步和第 6 步的编排你负责的是第 2 到第 5 步的内容。平台让链路能跑你让链路有价值。这就是底层交给平台之后还要做什么的完整答案。5. 实操中一定会遇到的坑与排查手册5.1 工具调用失败的高频原因速查Agent 产品上线后最高频的问题就是工具调用失败。我整理了一张速查表覆盖我遇到过的大部分情况现象可能原因排查方向工具完全不被调用工具描述太模糊模型没识别出适用场景优化 description加具体触发词工具被频繁误调用触发条件太宽泛收窄 description明确不适用场景调用参数格式错误inputSchema 定义不严加 required 字段加类型约束调用超时服务端处理慢或网络问题加超时配置服务端做异步鉴权失败凭证过期或权限不足检查凭证有效期核对权限范围返回结果被截断返回数据过大分页返回或做摘要这张表我建议直接贴到团队的排查文档里新人上手能省很多时间。5.2 Skills 触发不准的调优思路Skills 触发不准是另一个高频问题。表现是该用的时候不用不该用的时候乱用。调优思路分三步第一步看日志。把每次 Skill 触发和不触发的 case 都记下来看模型在什么情况下判断失误。这一步不能省凭感觉调是瞎调。第二步改描述。大部分触发问题都是描述问题。触发条件要写得像给模型看的说明书明确说清楚什么时候用我什么时候别用我。我一般会在 Skill 描述里加一句不适用于 XXX 场景效果很明显。第三步加兜底。对于关键 Skill可以在主流程里加一层规则判断模型没触发但规则命中时强制触发。这是工程手段兜底模型的不确定性。5.3 成本与延迟的平衡技巧Agent 产品跑起来之后成本和延迟是两个绕不开的指标。我的经验是不是所有请求都需要最强模型。简单请求用小模型复杂请求才上大模型路由逻辑可以基于请求复杂度判断工具调用能并行就并行。多个独立的工具调用并行发起比串行快很多缓存高频结果。知识库查询这类操作相同 query 的结果可以缓存命中率往往不低上下文要精简。历史对话不是越多越好无关历史会拖慢速度还增加成本该裁剪就裁剪注意缓存要设合理的过期时间尤其是数据会变的场景。我踩过的坑是缓存了知识库查询结果结果知识库更新了Agent 还在返回旧数据用户投诉了好几次。5.4 安全边界Agent 能做什么、绝对不能做什么最后讲安全这是 Agent 产品最容易出事的地方。核心原则是最小权限 关键操作人工确认。具体做法Agent 能访问的数据源按最小必要原则授权不要给全库权限涉及写操作、删除操作、对外发送的操作必须人工确认代码执行类操作要在沙箱里跑限制文件系统和网络访问所有操作留审计日志出问题能追溯我见过最危险的做法是给 Agent 一个全权限的 API key然后让它自由调用。这种设计一旦被 prompt 注入攻击后果不堪设想。安全不是上线前补的是设计时就要考虑的。6. 我个人的一些体会做 Agent 产品这两年最大的认知转变是不要和平台比谁更底层要和平台比谁更懂用户。平台的能力会越来越强抽象会越来越高这是不可逆的趋势。你越是把精力放在通用能力上越容易被下一波升级冲垮你越是把精力放在领域知识、工具生态、交互体验上平台的升级对你越是利好。我那个做垂直 Agent 的朋友现在产品活得不错靠的就是把行业里的判断规则沉淀成了几百条 Skill把行业专用软件对接成了十几个 MCP 服务端。这些东西平台不会做因为太垂直竞争对手抄起来也费劲因为需要行业 know-how。这才是平台之上真正的护城河。如果你现在正在纠结底层交给平台了我还能做什么我的建议是先把平台的边界摸清楚然后问自己一个问题——我的用户在这个领域里有哪些判断是只有专家才知道的把这些判断变成 Skill把这些判断依赖的数据源变成 MCP 服务端你的产品就有了平台给不了的价值。剩下的交给平台就好。