现状形态：三类市场、三种成熟度
「Agent 市场」不是单一事物，当前活跃的有三类，成熟度与逻辑差异很大。平台内置插件市场（成熟度最高）：超级助手/聊天平台内的插件与 GPT 类市场——形态上最像 App Store，实质上更接近「功能开关」：大部分「Agent」是提示词模板 + 少量工具调用的轻封装，开发者拿到的分发杠杆有限，收入更是杯水车薪（多数平台的插件经济从未真正起飞）。企业内部智能体市场（实用价值最高）：企业平台（协同办公套件、IT 平台）内的智能体目录——部门自建的智能体集中上架，供内部复用；它解决的是企业内的「重复建设」问题（每个部门都在造自己的智能体），是当前形态里最接近「真有用」的。第三方 Agent 商店（早期探索）：独立的智能体分发平台，想成为「智能体时代的应用商店」——它们面对的是本文最核心的问题：智能体作为「商品」的定义都还没稳定。
三类市场的共同背景音：平台方都把市场当作生态卡位的棋子（锁定开发者、丰富自家平台的供给），而开发者与用户的获得感参差——这个「平台热、两端冷」的温度差，是 Agent 市场生态的第一观察结论。
与 App Store 的结构差异：四点根本不同
「App Store 剧本重演」的类比在四个点上失效，这些失效点正是 Agent 市场的独特难题。
其一，商品形态：App 是成品，Agent 是能力。App 的功能边界在打包时确定（装了就是这些功能），Agent 的行为边界是动态的（它接什么模型、什么工具、什么数据，行为就不同）——「上架一个 Agent」上架的其实是一个会随环境变化的活物，平台难以对其行为做出承诺，用户也难以形成稳定预期。其二，执行风险：App 在沙箱里，Agent 要真权限。App Store 的安全模型建立在沙箱上（App 被限制在容器里），智能体的价值恰恰在于真实权限（操作文件、调 API、执行代码）——平台必须解决「市场化分发 + 真实权限」的治理，这是 App Store 从未面对的问题。其三，质量定义：App 看评分，Agent 看场景成功率。同一个智能体在你的工作流里 90 分、在我的工作流里 40 分（取决于模型、数据、任务的匹配），「平均评分」这个商品元数据的参考价值大幅缩水。其四，收入结构：App 的买断/订阅清晰，Agent 的价值计量天然倾向按结果（本库商业模式篇）——按结果收费的商品在抽成平台上如何结算（失败的任务退不退钱），平台的钱包与退款体系都没准备好。
flowchart TB
D["App Store 模式的四个失效点"] --> D1["App 是成品<br>Agent 是会变的能力"]
D --> D2["App 在沙箱<br>Agent 要真权限"]
D --> D3["App 看评分<br>Agent 看场景成功率"]
D --> D4["App 买断订阅<br>Agent 倾向按结果结算"]
D1 & D2 & D3 & D4 --> G["Agent 市场的真实难题：<br>信任机制与结算体系"]
质量与信任：市场生态的真正缺口
App Store 用一套成熟机制建立了信任：审核（上架前的人工与自动审查）、沙箱（运行时隔离）、评分（事后反馈）、退款（纠错机制）。Agent 市场四件套的对应物全部缺位或原始。上架审核的难题：审查智能体的「行为」比审查 App 代码难得多——提示词、工具组合、模型组合的排列空间近乎无限，静态审查测不出动态行为（恶意行为可以藏在特定输入的分支里）。运行时治理的难题：智能体在生产中「学会」的行为变化（上下文里的注入、数据的偏移）不受平台控制——上架时的审查不保证运行时的清白。声誉机制的难题：评分可以被刷，且智能体的「差评」归因困难（是 Agent 不行还是我的用法不行）。结算与责任的难题：智能体出错造成损失，平台、开发者、模型厂商的责任分配没有惯例。
信任机制的缺位解释了当前 Agent 市场的「冷」：用户不敢把关键任务交给市场上三无（无审核、无担保、无溯源）的智能体，开发者面对「分发杠杆有限 + 收入微薄 + 责任无限」的组合也不积极——两端的冷清互为因果。破局的次序大概率是：先在企业内市场成熟（信任靠内部治理背书，本库第 5 篇的平台团队模式），再外溢到行业垂直市场（行业间有信任锚，如律协、医委会的认证），最后才是消费级的开放市场——信任的建设次序与 App Store 相反：App Store 从消费级起家，Agent 市场要从企业级爬坡。
给参与者的务实建议
对开发者：现阶段不要把 Agent 市场当主要分发渠道（杠杆有限），把它当「陈列位」；真正的分发靠场景嵌入（进平台的工作流）与垂直深耕。对平台方：市场项目的优先级不是「数量」，是信任基建的样板（审核沙箱、行为日志、分级担保的试点）——谁先解决「敢用」的问题，谁的市场才会热。对企业：内部市场值得建（复用与治理的真实价值），对外采购智能体时把「市场的存在」视为弱信号（上了架不等于可信，本库安全篇的供应链四句清单仍是主筛）。
企业内部市场的运营手册：从目录到治理
企业内部 Agent 市场（正文判断的当前最实用形态）要真正运转，需要一份运营手册——只有目录没有治理的内部市场会迅速退化为「僵尸仓库」。运营手册的核心章节。上架标准：不是「做出来就能上」——最低要求建议四条：有明确的业务 owner、通过了平台团队的评测基线（回归集分数达标）、接入了统一的观测（轨迹可查）、有使用说明与已知限制的文档。生命周期管理：智能体有生老病死——业务下线的智能体要下架（僵尸智能体的持续运行是成本与安全的双重隐患）、模型换代后要重测（老分数不作数）、长期无使用的要归档清理。复用激励：内部市场繁荣的条件是「造轮子的人有收益」——被复用次数进入部门的数字化贡献统计（IT 治理的考核指标）、热门智能体的作者有奖励机制；没有激励的市场，部门会选择「自己藏着用」。治理的角色划分：平台团队管「准入与基建」（评测基线、观测接入、安全扫描），业务部门管「内容与质量」（自己领域的智能体自己负责），市场运营（通常是平台团队兼）管「目录的秩序」（分类、搜索、生命周期清理）。三方的权责清晰是内部市场不出乱子的前提——企业软件领域「目录变坟场」的历史教训（内部工具市场、共享服务目录）都在提醒：市场的技术实现只占三成，运营机制占七成。
Agent 市场的信用评分设想：一个值得做的原型
Agent 市场的信任缺口（正文）有一个值得原型化的解法：智能体的信用评分体系——类比卖家信用分，但按智能体的特性重新设计。评分的构成。能力分：在标准化任务集上的实测成功率（平台定期跑分，而非开发者自报）；稳定分：运行历史上行为的一致性（无突然的行为漂移、无安全事故记录）；合规分：标识、审计日志、数据处理的合规完备度；场景分：分场景的细分评分（「它在数据抽取类任务上 92 分、在创意写作上 61 分」——总分无意义，场景分才有用）。反 gaming 的设计：分数由平台的隐藏保持集实测（开发者刷不了）、扣分原因公开（可申诉）、评分的更新有滞后（防短期表演）。这个设想的现实意义：它把 Agent 市场的「敢用」问题转化为可工程的对象——评分不是完美的信任，是「可比较的信任」（比三无市场的一无所知强一个数量级）；对企业采购，场景分是 supplier 筛选的初筛工具；对开发者，评分是把「能力」变成「可定价资产」的计量器。谁先把这个原型做出来并跑出数据（平台、行业协会或第三方评测机构），谁就握住了 Agent 市场生态的发牌权——这是比「再做一个商店」价值高得多的创业题目。
Agent 市场的一个先行信号：B 端采购的「目录化」
Agent 市场生态（正文）的一个先行信号值得追踪：企业采购流程里「智能体目录」的出现——大企业的 IT 采购开始建立「已审核智能体/工具的内部目录」（采购前的安全审核、合规评估、试点验证的记录沉淀为目录条目），业务部门从目录里选、绕过目录的要走特批。这个信号的意义在于：企业级的「信任分层」已经先于消费级市场形成——目录内 = 已审 = 可用，目录外 = 未审 = 需流程。它的连锁反应：进目录成为供应商的竞争目标（审核标准成为事实上的产品要求清单）、目录的审核标准成为行业默认规范的雏形（本库安全篇与市场篇的信任基建，最先在企业采购场景落地）。给供应商的启示：B 端智能体产品的销售素材里，「可进客户目录的完整材料包」（安全白皮书、审计日志样例、合规声明、试点案例）正在从加分项变成入场券——把这份材料包当产品功能来做（而非销售的事后拼凑），是进入企业目录赛道的先手棋。
小结
Agent 市场三类形态：平台插件市场（平台热两端冷）、企业内部市场（当前最实用，解重复建设）、第三方商店（早期探索）。App Store 类比在四点失效：Agent 是活的能力不是成品、要真权限不在沙箱、质量看场景成功率不看评分、结算天然倾向按结果。真正的缺口是信任机制四件套（审核、运行时治理、声誉、责任结算）全部缺位或原始——两端冷清互为因果。信任建设次序与 App Store 相反：企业内市场先行，垂直行业次之，消费级开放市场最后。开发者把市场当陈列位，平台先建信任样板，企业把市场当弱信号。
读者留言
COMMENTS 暂无还没有留言，来说第一句？