字号·· | 护眼
thenextweb

AI交易代理面临人类应用从未有过的可靠性门槛AI trading agents face a reliability bar human apps never did

点「原文对照」整页切到原文,或双击某段只看那段的原文。

AI代理 图片来源:CanvaAI Agents Credit: Canva

想象一下,有两个 AI 交易代理运行着相同的模型和相同的策略。在快速变化的市场中,一个信号到达,两者都发送了订单,而一个平台在毫秒级响应,另一个则超时。智能相同,结果却不同。

Picture two AI trading agents running the same model and the same strategy. A signal arrives during a fast market, both send an order, and one platform answers in milliseconds while the other times out. Same intelligence, different result.

差异在于管道。随着代理承担越来越多的交易工作,连接它们与市场的基础设施在它们实际能够交付的内容中发挥着越来越重要的作用。

The difference sat in the plumbing. As agents take on more of the work of trading, the infrastructure connecting them to markets plays a growing role in what they can actually deliver.

约束正从模型转向管道。对于消费者应用,可靠性是用户体验问题。延迟意味着转圈的加载轮,用户会再次点击。而对于代理而言,这会变成正确性问题。一个执行数百次自动调用的代理会将超时视为数据缺失,因此可能基于过时的账户信息进行操作,跳过检查,或在更不利的价格下重试订单。

The Constraint Is Moving From the Model to the Pipe For a consumer app, reliability is a user-experience problem. A delay means a spinning wheel, and the person taps again. For an agent it turns into a correctness problem. An agent making hundreds of automated calls reads a timeout as missing data, so it may act on stale account information, skip a check or retry an order into a worse price.

这种差距正在吸引资金。Arcade 在 6 月份筹集了 6000 万美元,基于这样的观点:大多数代理之所以失败,是因为它们周围的基础设施尚未准备好。TechCrunch 报道称,MCP 服务器不得不做额外工作,仅仅是为了在负载均衡的机器之间追踪会话,这也是大规模集成推出缓慢的一个原因。

That gap is drawing money. Arcade raised $60 million in June on the view that most agents fail because the infrastructure around them isn’t ready, and TechCrunch reported that MCP servers have had to do extra work simply to track sessions across load-balanced machines, one reason large integrations were slow to ship.

“市场不会因有人关闭应用或离开屏幕而停顿。Agent OS的早期采用表明,对能够在市场条件变化时保持连接的代理的需求正在增长:第一周,MCP连接数翻倍,通话量增加了二十倍;两周内,每日请求量超过90,000,其中95%的请求在60毫秒内完成,成功率达97%。”币安产品副总裁Jeff Li表示。“市场准入的下一阶段将不仅由代理能做什么来塑造,还将由它们在市场波动时能多快、多可靠地响应来决定。”这些数据值得仔细研读。

“Markets do not pause when someone closes an app or steps away from a screen. The early adoption of Agent OS points to growing demand for agents that can remain connected as market conditions change: in the first week, MCP connections doubled and call volumes increased twentyfold, within two weeks, daily requests exceeded 90,000 with 95% completed within 60 milliseconds and a 97% success rate,” says Jeff Li, VP of Product at Binance. “The next phase of market access will be shaped not only by what agents can do, but by how quickly and reliably they can respond when the market moves.”Those figures reward a close reading.

第95百分位结果意味着每20个请求中就有1个耗时超过60毫秒,而在快速变化的市场中,这个较慢的尾部正是关键所在。以97%的成功率计算,一个每日处理超过90,000个请求的系统,按简单算术,每天大约会有2,700个请求失败。公布的数字也未说明延迟是在何处测量的,以及什么算作失败。

A 95th-percentile result means one request in 20 took longer than 60 milliseconds, and fast markets are exactly where that slower tail matters. At a 97% success rate, a system handling more than 90,000 daily requests would see roughly 2,700 fail each day, by simple arithmetic. The published numbers also leave open where latency is measured and what counts as a failure.

图片来源:币安学院Credit: Binance Academy

在Agent规模下,延迟、成功率和负载下的行为这三个指标看似独立。但对代理而言,它们是相乘的关系。一个人发送一个请求并作出反应,而代理则会将多个请求串联起来。假设一个工作流需要五次顺序调用来检查余额、读取订单簿、确定仓位大小、下单并确认成交,且每次调用独立成功的概率为97%。那么,整个序列完整成功的概率约为86%。

Three Numbers That Compound at Agent Scale Latency, success rate and behavior under load look like separate metrics. For an agent they multiply. A person sends one request and reacts, while an agent chains several together. Suppose a workflow needs five sequential calls to check a balance and read the order book as well as size a position and place the order and confirm the fill, and each call succeeds 97% of the time independently. In that case the full sequence completes cleanly about 86% of the time.

负载是这三个指标中最难以应对的一个,因为需求激增恰恰发生在价格波动时,而故障往往在这最糟糕的时刻聚集。MCP的维护者在七月份转向了无状态设计,使得服务器可以在标准负载均衡器后运行,而无需依赖单台机器来记住每个会话。

Load is the hardest of the three, because demand spikes precisely when prices move and failures tend to cluster at the worst moment. MCP’s maintainers moved to a stateless design in July so servers can run behind standard load balancers without relying on one machine to remember each session.

“之前,你需要有一个会话存储来存储和管理会话 ID,如果其中一个计算 Pod 突然宕机,所有请求就会瞬间开始失败,” MCP 的主要维护者 Den Delimarsky 说。

“Before, you needed to have a session store and manage session IDs, and if one of your compute pods went down, all of a sudden the requests would start failing,” says Den Delimarsky, a lead maintainer of MCP.

Binance Research 在分享其两周数据时也提出了类似观点:随着代理能力的提升,限制可能会越来越多地从模型智能转向访问数据和可靠执行所需的基础设施。

Binance Research made a related point when it shared its two-week figures: as agents become more capable, the constraint may increasingly shift from model intelligence to the infrastructure needed to access data and execute reliably.

自动化系统在机器速度交易中会失败,这一点曾被 Automated Systems Fail at Machine Speed Trading 以高昂代价学到。2012 年 8 月 1 日,Knight Capital 的一次错误软件部署在试图处理 212 个客户订单时,在 45 分钟内向市场发送了超过 400 万笔订单。根据后来与 Knight 达成的 $1200 万和解协议,SEC 报告称该公司交易了超过 3.97 亿股股票,损失超过 4.6 亿美元。

Automated Systems Fail at Machine Speed Trading has learned this before, at considerable cost. On August 1, 2012, a faulty software deployment at Knight Capital sent more than 4 million orders into the market in 45 minutes while trying to fill 212 customer orders. The firm traded more than 397 million shares and lost more than $460 million, according to the SEC, which later settled market access rule charges with Knight for $12 million.

对于代理构建者来说,这一教训令人不安。自动化系统可能在任何人来得及干预之前就发生故障,因此可靠性必须从一开始就被设计进去。

For agent builders, the takeaway is uncomfortable. Automated systems can fail faster than anyone can step in, so reliability has to be designed in from the start.

支付系统经历了类似的演变。卡网络和结算系统仍在可用性和吞吐量上竞争,但随着时间的推移,这些特性已成为处理他人资金的入场券。代理平台似乎也将走这条路。一旦某个平台公布了延迟和成功率数据,其他平台也将被要求提供类似数据,而公布的数字将变成底线。

Payments went through a similar evolution. Card networks and settlement systems still compete on availability and throughput, yet over time those properties became the price of entry for handling other people’s money. Agent platforms look set to follow. Once one publishes latency and success-rate figures, the others will be asked for theirs, and the published number turns into a floor.

在代理触及资金之前应提出的问题:任何将代理连接到有资金账户的人都可以向平台提出几个直接的问题。延迟是在哪个百分位数报告的?是服务器端还是端到端测量的?什么算作请求失败?代理在遇到失败后会做什么?

Questions to Ask Before an Agent Touches Money Anyone connecting an agent to a funded account can put a few direct questions to the platform. At which percentile is latency reported, and is it measured at the server or end to end? What counts as a failed request, and what does the agent do after one?

上下文与平均值同样重要。这些数据在最波动日最繁忙时段的表现如何?与发布周初的快照相比又如何?是否存在速率限制?超过限制的请求会怎样处理?平台是否会随时间公布这些数字,还是仅公布一次?

Context matters as much as averages. How did the figures hold up during the busiest hour of the most volatile day, compared with a launch-week snapshot? Are there rate limits, and what happens to requests above them? Does the platform publish these numbers over time, or only once?

代理平台可能会像交易所发布系统状态那样,越来越多地发布执行指标。那些持续这样做的平台将使上述问题变得更容易回答。投稿文章。非TNW新闻室制作,也不代表TNW的编辑立场。

Agent platforms may increasingly publish execution metrics the way exchanges already publish system status, and the ones that do it consistently will make those questions much easier to answer. Contributed article. Not produced by the TNW newsroom and does not reflect the editorial stance of TNW.