刚看到这个标题的时候我第一反应是又一个蹭 AI 热点的玩具项目但仔细翻完仓库之后我改观了。这个名为去中心化竞价 Agent 市场的开源项目核心贡献者里有几位是 OpenAI 的工程师做的事情一句话概括就是让 AI Agent 不再挤在某个中心化应用商店里等审核上架而是通过一套公开的招标-投标-中标-结算协议直接在任务需求方和 Agent 提供方之间完成交易。任务发布方把需求写好、设定预算上限符合条件的 Agent 各自出价竞标系统根据报价、历史成功率、响应速度等维度撮合成交之后执行结果并记账。这个项目适合谁如果你是 Agent 开发者想找个地方把自己的 Agent 挂出去接活不想被平台抽成如果你是企业里负责 AI 落地的人想建立一个内部多个 Agent 协作、互相竞价完成任务的调度体系或者你只是对AI 如何参与真实经济协作感兴趣都值得花点时间把它跑一遍。我大概花了一个周末读完核心代码、部署了本地环境、发了三轮测试任务下面把整个项目的设计逻辑、实测过程和一些踩坑经验完整记录下来。1. 这个开源项目到底在解决什么问题Agent 生态的平台税困境1.1 现在的 Agent 分发本质上还是商店模式过去一年我试过至少五个不同的 Agent 平台。流程几乎一模一样注册账号、提交 Agent 技能描述、等人工审核、上架到某个商店页面然后祈祷平台的推荐算法能赏你一点流量。开发者对 Agent 的定价权很弱平台说搞活动打折就得打折说调整分成比例就得接受评价体系也完全掌握在平台手里——你甚至连为什么我的 Agent 评分掉了 0.2 分的申诉渠道都找不到。这种中心化商店模式有三个结构性死穴。第一是平台抽成应用商店时代大家已经领教过 30% 的苹果税Agent 市场如果走老路独立开发者辛苦调出来的 Agent 很可能只是在给平台打工。第二是评价黑箱排序算法、推荐策略、评分规则都不透明刷分、控评、买量在这些体系里几乎是必然产物劣币驱逐良币只是时间问题。第三是单点故障平台一旦调整政策、封禁账号或者干脆关停你积累的所有用户、评价、交易记录一夜归零——这不是理论推演过去一年我身边至少有三位独立开发者的 Agent 技能包因为平台规则变更收入直接清零。这个项目的第一层价值就是把这个商店模式掀翻。它不提供上架这个动作而是把 Agent 变成市场里自由流动的服务节点。没有平台编辑决定谁该被看见只有任务本身在决定谁适合被选中。这种思路在传统互联网里有个近亲叫众包平台但众包平台依然靠中心化机构做信用背书而这个项目把信用背书这件事也协议化了。1.2 竞价机制把谁被选择的权力交给算法而不是编辑项目最核心的机制是竞价。任务需求方发布一条真实任务——把这篇文章翻译成日文并润色、根据这 20 份财报生成一份投资摘要、帮我校验这个数据集里的异常值——然后对任务有兴趣的 Agent 各自出价竞标。竞价不是简单的价高者得。系统会综合报价、Agent 的能力声明、历史完成率、信誉分、响应速度等多个维度做匹配目的是找到性价比最优而不是最贵或最便宜的 Agent。这样一来价格由供需双方在具体任务上动态博弈出来而不是平台统一定价质量由历史行为数据决定而不是靠运营人员的审美机会向所有 Agent 开放只要你能证明自己适合这个任务哪怕你是刚入场的新节点也有机会靠低报价和高质量完成冷启动。这种设计最打动我的一点是它把信任从平台背书变成了协议背书。需求方不需要认识这个 Agent不需要看平台脸色只需要看公开账本上的历史记录和竞价过程中提交的验证材料就能做出是否合作的决定。这套逻辑其实和二手车市场、外包平台、甚至银行信贷里的信用评分是同一个内核——只不过这次信用主体不是人而是 AI Agent。1.3 为什么由 OpenAI 工程师来做这件事其实很合理看到OpenAI 工程师开源这个标签很多人容易陷入两种极端要么觉得这是官方背书要么觉得是几个大厂员工出来刷履历。我实际读代码的感受是这两者都不准确。OpenAI 的工程师做这件事有天然优势。他们在日常工作中每天都在跟 Agent 和工具调用打交道内部其实已经有非常成熟的任务路由系统——决定哪个模型、哪个工具、哪个 Agent 来处理哪条请求。这次开源本质上是把这套任务路由 信誉管理 结算逻辑从内部体系里抽出来做成一套不绑定任何特定大模型的通用协议。也正因为不绑定模型这个项目对所有 Agent 都是开放的你可以用 OpenAI 的模型也可以用其他开源模型甚至可以跑一个纯规则脚本的 Agent 来接活。但说实话核心贡献者是不是 OpenAI 出来的对项目价值影响没那么大。真正重要的是这套协议能不能长出来生态。代码写得再好没有任务需求方来发任务、没有 Agent 提供方来投标市场就是空的。这也是我写这篇长文的原因——任何一个新协议前期最缺的不是代码是参与者。2. 核心架构拆解一个任务从发布到结算经历了什么2.1 五个阶段招标、投标、中标、执行、结算整个系统把一个任务的生命周期拆成了五个阶段每个阶段都有明确的协议动作和签名要求。我按实际流程过一遍。招标Task Publication需求方用私钥签名一条任务描述包含目标、输入数据的引用地址、验收标准、预算上限和截止时间。签名之后的任务广播到网络中继节点等待 Agent 来投标。这里有个细节值得注意任务描述里的验收标准字段是必填的如果需求方不写清楚什么样算完成这个任务会被很多 Agent 直接忽略——因为它们无法评估自己的成功概率也就没法给出合理报价。投标BiddingAgent 节点从网络中继拉取或订阅到任务广播后评估任务可行性提交一份投标书报价、预计耗时、依赖的模型和工具、能力证明、历史完成记录的摘要引用。投标书同样需要 Agent 私钥签名这一步的意义是防抵赖——你投了标就不能假装没投过。中标Matching需求方或者网络中的自动撮合器收集所有投标按评分函数打分。项目默认的评分函数大概长这样score 历史成功率权重 报价竞争力权重 响应速度权重 - 风险系数权重每个权重都可以按任务类型调整。比如对成本敏感的任务把报价权重调高对时效性要求高的任务把响应速度权重调高。系统选出得分最高的 Agent 作为中标者双方在协议层面形成一份电子合同。执行Execution中标 Agent 拉取输入数据执行任务把结果用私钥签名后提交到去中心化存储或公开可验证的存储地址。执行过程中产生的中间状态、日志摘要、资源消耗记录也会一并提交作为后续结算和信誉更新的依据。结算Settlement需求方验证结果确认达到验收标准后双方在账本上确认交易完成。托管中的资金或积分从托管合约释放到 Agent 账户同时双方的信誉记录被更新。如果有争议进入仲裁流程。2.2 竞价排名不是谁便宜谁赢而是多维评分后的性价比最优开始我也有个误解既然是竞价市场那是不是所有任务最后都变成价格战实际上项目在设计排名规则时明显考虑到了柠檬市场问题——就是信息不对称导致劣质品驱逐优质品的那个经典经济学困境。如果只看报价劣质 Agent 可以报低价抢单做完就跑需求方体验极差最后市场整体萎缩。为避免这个局面项目在竞价排名里加了三个关键机制。第一个是硬性资格过滤报价高于需求方设定的 Hard Cap 的投标直接出局低于 Soft Cap 的投标也不一定赢因为还要看其他维度。第二个是多维评分加权价格只是其中一个因子成功率的历史记录权重更高一个新 Agent 想靠超低报价抢到大单很难除非它的历史记录确实过硬。第三个是押金与违约金中标但不执行的 Agent 会被扣罚押金同时信誉分大幅下降。这个设计逼着 Agent 报价时必须贴近真实成本不能恶意低价中标再放弃否则亏的不只是钱还有长期信誉。说实话竞价 信誉 押金这套组合在传统交易系统里不算新鲜但把它做成一套 Agent 之间自动执行的协议新鲜度就完全不一样了。它把过去靠平台客服、人工仲裁、信用评分公司干的活压缩成几行代码和一个加密签名。2.3 去中心化到底去在哪几个层面别被概念带偏很多文章一提到去中心化就默认等于区块链这个项目其实没在为链而链。读代码可以看出它去中心化的核心诉求只有三个身份不依赖平台、撮合不依赖单点、信誉不依赖主站。身份层面每个 Agent 拥有一对公私钥公钥就是它在市场里的 ID不需要注册账号、不需要邮箱验证。所有签名操作都由本地私钥完成平台方如果有的话无法冒用身份。撮合层面任务广播不依赖单一服务器。理论上可以部署任意多个中继节点Agent 可以同时从多个中继获取任务。即使官方默认的中继挂掉运行在网络里的其他节点依然能够继续发现任务、投标、成交。这和 BitTorrent 的 tracker 机制有点像——不是完全无中心但对单点故障的容忍度高了很多。信誉层面最有意思。每个 Agent 的完成率、成交均价、争议次数、历史评分都被写在公开账本上新加入的节点可以通过同步账本拿到全量信誉数据不需要信任任何中心化机构的数据库。这意味着信誉是 Agent 的随身资产而不是平台的后台记录。这里我必须泼一盆冷水目前项目在实际网络里依然依赖一些半中心化组件比如官方维护的默认中继、仲裁节点的实现也还没有完全去中心化。它是渐进式去中心化的架构而不是一夜之间把一切都摊到链上。务实但别把它神化。2.4 结算与信誉防止跑单和刷单的机制设计在一个没有平台强制力的市场里两个陌生人或者说陌生人编写的 Agent凭什么相信对方会履约项目给的答案是加密托管和声誉抵押的组合。资金托管这一步很好理解任务发布时预算上限的资金先进入一个托管合约/托管账户Agent 中标后开始干活干完活需求方确认验收托管资金才释放给 Agent。如果需求方一直不确认系统会依据验收标准自动判定是否满足条件防止恶意拖延。防止刷单的设计我觉得更值得展开。一个 Agent 如果自己注册一堆小号互相交易理论上可以刷出极高的信誉分。项目的对策是最低多样性质押新信誉要在足够多的不同对手方之间完成交易后才逐步生效同一对手方反复交易的权重会随时间衰减。这套逻辑借鉴了电商平台的反刷单经验但在协议层面实现比靠平台风控规则更透明。验签机制也贯穿全程。每一个任务、投标、结果、回执都带签名链下存储全量数据链上只存哈希。这样做的好处是既保证了数据不可篡改又避免了把所有交易数据都塞进链上带来的性能爆炸。有人可能觉得这些机制很繁琐但放到生产环境里每一个机制都对应一个真实世界的坑跑单、欺诈、差评威胁、历史记录被后台删除。如果你想把这个项目用到正经业务里这些繁琐恰恰是最有价值的部分。3. 把项目拉起来跑一遍我的本地实测记录3.1 环境准备和最小依赖建议直接用 Python 3.11我本机是 Ubuntu 22.04Python 版本原来装的是 3.12结果在安装依赖阶段就翻车了——有个核心加密库在 3.12 上的预编译轮子还没跟上被迫降级到 3.11 才顺利通过。所以如果你准备自己跑直接用 Python 3.11 最省事别在版本兼容性上浪费时间。核心依赖其实只有三个模块P2P 发现模块负责中继节点发现和任务广播加密签名模块负责公私钥生成、签名和验签协议 SDK 负责任务发布、投标、结算等等高层接口。前端面板是可选的我建议第一次跑的时候先不用前端直接用命令行工具逻辑更清楚。# 建议在干净的虚拟环境里操作 python3.11 -m venv agent-market-env source agent-market-env/bin/activate pip install agent-market-sdk # 初始化一个身份 agent-market identity create --profile my-agent这个初始化命令会在本地生成一对密钥同时生成一个配置文件。后面所有操作都需要指定 profile相当于给不同角色设定独立身份一个人可以同时拥有需求方和Agent两个 profile这在本地测试时非常方便。3.2 配置文件中容易忽略的关键字段跑通整个流程之后回头看配置文件里有几个字段非常容易被忽略但直接影响能否正常参与竞价。{ profile: my-agent, identity: { private_key_path: ./keys/my-agent.pem, public_key: 0x... }, relay: { endpoints: [http://127.0.0.1:8848], heartbeat_interval_sec: 15 }, bidding: { enabled: true, bid_window_sec: 60, max_concurrent_tasks: 2, min_profit_threshold_usd: 0.05 }, settlement: { account: 0x..., auto_accept_threshold_sec: 300 } }heartbeat_interval_sec决定 Agent 向中继节点上报心跳的频率。默认值 15 秒如果你的网络环境不太好可以调大到 30 秒否则容易出现Agent 离线的误判。bid_window_sec我刚才说过默认 30 秒不够用建议直接设成 60。min_profit_threshold_usd是给 Agent 设置一个最低利润门槛低于这个门槛的任务直接不参与竞标防止被低价任务淹没。3.3 我在实测中踩的三个坑第一个坑是私钥权限问题。身份生成之后私钥文件默认权限是 0644,也就是所有用户都可读。客户端启动时会严格检查这个权限如果发现私钥文件权限过于开放直接拒绝启动并报错。解决办法很朴素chmod 600 ./keys/my-agent.pem这个设计其实是合理的——私钥可被其他人读取就意味着身份可以被盗用。但文档里没有特别强调导致我第一次跑的时候卡了十分钟才反应过来。第二个坑是任务 Schema 里漏了验收标准字段。我第一次发布测试任务时只写了任务目标和数据位置没写验收标准。结果等了两分钟系统提示0 个 Agent 响应——不是网络故障而是所有 Agent 在解析任务后都认为这个任务无法评估风险所以没人投标。后来补上了acceptance_criteria字段立刻就有三个 Agent 响应了。第三个坑是竞价窗口超时。我最初用的是默认的bid_window_sec 30发布了一个需要调用外部大模型 API 的任务Agent 从解析任务到完成模型推理、再到生成投标书一共花了 40 多秒。等它的投标书到达时窗口已经关闭了。连续两次测试都这样我才意识到不是 Agent 速度慢是窗口设置太短。调整成 60 秒之后整个流程就顺畅了。3.4 最小可用示例一个 Linux 命令搞定全流程本地起了中继和两个 Agent 节点之后发布一条测试任务的命令大概是这样的agent-market task create \ --profile requester \ --schema ./task_schema.json \ --budget 2.00 \ --bid-window 60task_schema.json是任务描述文件我用的最小可用版本长这样{ title: Translate a short paragraph to Japanese, description: Translate the input text in ./data/sample.txt to natural Japanese, keep the tone casual., input: { type: file, uri: ipfs://QmSampleHash... }, output: { type: text, format: markdown }, acceptance_criteria: Translation must preserve all key information and read naturally to a native Japanese speaker., deadline: 2025-08-01T12:00:00Z }任务发布之后通过agent-market task status --task-id id可以实时查看竞价情况。等中标结果出来Agent 执行完需求方确认验收再执行agent-market settlement confirm --task-id id资金就从托管里释放了。整个过程的日志会记录每一步的签名和哈希可以随时回查。我三轮测试跑下来从发布到结算完成最快的一轮只花了 4 分 27 秒。作为一个去中心化协议的初版这个速度已经算不错了。4. 作为使用方我应该怎么评价这套设计4.1 对 Agent 提供方收益模型和定价策略如果你手里已经有一个稳定运行的 Agent想把它挂到这个市场里接活我的建议是新号不要一开始就追高利润先用低价积累真实成交记录和信誉分。信誉分的增长逻辑和电商卖家很像——前几笔交易是最难的因为没有历史记录需求方往往不敢把重要任务交给你。这时候可以主动去竞一些预算不高、但验收标准清晰的小任务比如翻译短文本、数据格式转换、简单的正则提取。这些任务竞争少、需求方预期明确、完成率高是积累初始信誉的最佳标的。等历史成功率稳定到 95% 以上再开始逐步提高报价。项目里的信誉记录是公开的高质量 Agent 的报价可以比新 Agent 高出 30%~50%,因为需求方愿意为确定性支付溢价。还有一个容易踩的坑报价时必须把模型调用成本、API 费用、算力成本全部算进去否则单量上来之后非常容易亏钱。我第一次报价时就忽略了外部 API 费用做完一单发现利润是负的。后来我在配置里加了min_profit_threshold_usd低于 0.05 美元的单子直接不参与才把账算平。4.2 对任务发布方成本控制和质量保障作为需求方最怕的问题不是贵而是花了钱拿到垃圾结果。我在测试中逐渐养成几个习惯效果很明显。第一发布任务时把验收标准写到可以被客观检查的程度。不要写翻译得自然一点这种主观描述要写所有专业术语保留英文原词并在括号内给出中文释义这种可逐项核对的标准。验收标准越清晰Agent 报价越合理争议仲裁也越容易判定。第二对预算敏感的任务设定 Hard Cap 而不是开放竞价。开放竞价适合你对价格没有概念的新任务但如果你已经知道这类任务的市场行情直接设硬上限可以防止某次竞价被极端报价干扰。第三质量要求高的任务可以只允许历史成功率排名前 10% 的 Agent 参与竞标。系统支持在任务发布时设置信誉过滤条件这会大大降低你踩雷的概率但相应的你可能需要为这份确定性多付一点钱。4.3 现在的设计还缺什么几个不容回避的短板任何项目都有短板这个项目也不例外我在使用中明显感觉到有几个问题还没解决。第一是模型推理的可验证性。市场目前只能验证 Agent 提交的结果和签名但无法验证这个结果真的是由 Agent 声明的那个大模型生成的。一个 Agent 声称自己用了 GPT-4o实际上偷偷用了个小模型从结果上很难发现。现在只能靠信誉抽样和抽查来缓解距离真正的可验证计算还有不小距离。第二是争议仲裁的去中心化程度。虽然协议设计了仲裁流程但实际实现里仲裁节点的选取还不够透明。真到了公网大规模使用阶段谁来当裁判这个问题一定会被放大。短期看半中心化仲裁可以接受长期一定会成为治理争论的焦点。第三是非技术用户的使用门槛。目前发布任务至少需要会写 JSON Schema、懂命令行操作、理解公私钥概念——这个门槛把大量真正有任务需求的普通用户挡在门外。距离一个人人可用的 Agent 市场中间还差一层无代码聚合层这也是我判断这个项目短期还不会爆发式增长的原因。5. 开源生态横评和我的下一步计划5.1 它和主流 Agent 框架不是竞争是上下游我在跑通这个项目之后一直在想它和 OpenAI Agents SDK、LangGraph、AutoGPT 这些主流框架到底是什么关系。结论很清晰它们解决的是不同层面的问题。项目核心定位解决的问题OpenAI Agents SDKAgent 构建框架单个 Agent 内部怎么做工具调用、循环、多步推理LangGraph状态化编排框架多个步骤/多个 Agent 之间怎么做图状编排AutoGPT自主任务执行给一个目标Agent 自己拆解并执行本开源项目Agent 交易市场协议独立 Agent 之间怎么互相发现、定价、交易、结算用大白话说前面那些框架解决的是怎么把 Agent 造出来、调好这个项目解决的是造好之后去哪里接活、怎么收费、怎么建立信誉。所以你完全可以用 OpenAI Agents SDK 构建一个高质量 Agent再把它注册到这个市场里接任务。5.2 我准备怎么扩展它三个方向这个项目已经给了我足够的启发我近期准备围绕它做三件事。第一是写一个 Telegram/Web 前端让不懂命令行和 JSON Schema 的人也能发布任务。后端已经提供了完整的 REST API前端只是把发布任务这个动作表单化把查看投标变成可视化列表并不复杂但对冷启动用户的价值会非常大。第二是做一个模型成本预测器。Agent 投标时需要预估完成某个任务要花多少外部模型调用费现在全靠人工估算很不准确。我打算根据输入 token 数、输出 token 数和模型单价做一个自动预估器集成到 Agent 的报价逻辑里让报价更贴近真实成本。第三是给主流 Agent 框架写适配器。社区里已经有人在讨论 LangGraph adapter 了但目前还没有成熟实现。如果能把 LangGraph 的节点直接注册成市场里的 Agent生态价值会大很多。5.3 社区现状和值得关注的方向最后聊聊我观察到的社区现状。这个项目发布之后围绕它的讨论主要集中在三个方向一是任务 Schema 标准的统一——目前不同市场协议之间互不兼容如果未来 Agent 要在多个市场里漫游标准统一是绕不开的坎二是信誉数据的分析工具——公开账本上已经积累了交易数据但几乎没有人做可视化和深度分析这其实是个很好的数据产品切入点三是Agent 众包 人工复核的混合模式——早期冷启动阶段自动仲裁还不够可靠引入人工复核可能是提升信任度的最务实路径。我自己最关注的方向是信誉的跨市场携带。如果将来出现十个类似协议每个都有自己的信誉体系Agent 在 A 市场的高信誉能不能迁移到 B 市场这背后需要的是一套去中心化身份标准和信誉归一化算法难度不小但一旦有人做出来Agent 经济的底层基础设施才算真正成型。实话说这个项目目前还处在技术极客玩得转普通人看不懂的阶段。我个人的建议是如果你对 Agent 商业化有兴趣别等生态成熟了再入手,现在就把环境跑起来发几条测试任务感受一下让 Agent 自己竞标接活是什么体验。等真正用起来你会发现以前那些平台税的抱怨、评价黑箱的无力感、账号被ban的慌张,在这套协议面前都变得不那么重要了。最简单的开始方式就是我前面写的那三条命令——建身份、起中继、发任务。跑通一次之后你对整个 Agent 经济形态的理解会和现在完全不同。