自主智能体的技术栈：实现市场化交易的信任、市场与控制平面

Aaron Wright 2026-05-20 62.2 KB 74.8K 298 𝕏 文章列表

文章探讨了自主智能体从生成式工具转变为真正资产类别的关键技术堆栈。作者指出，智能体若要进入市场并有效交易，必须建立超越单纯“智能”的基础设施。文章提出了由信任平面（身份、发现、声誉）、市场平面（定价、结算、流动性）和控制平面（授权、合规、协调）构成的十层架构。文中重点分析了 ERC-8004 标准在建立链上身份和互操作性方面的作用，并详细阐述了身份验证、能力注册和声誉追踪这三个信任层级目前存在的缺失与未来的解决方案。

# The Technical Stack for Autonomous Agents. **作者**: Aaron Wright **日期**: 2026-05-19T20:58:10.000Z **来源**: [https://x.com/awrigh01/status/2056841869594918918](https://x.com/awrigh01/status/2056841869594918918) --- ![Image](/doc/2108/image/img_853e4f99d9c2.jpg) If autonomous agents are going to become a true asset class, they cannot just generate output. They have to transact. They have to find counterparties, make commitments, move money, build a track record, survive disputes, and stay inside the bounds of what its principal actually authorized it to do. In other words, they have to enter a market -- and operate inside the rules of one. That is the missing layer in most conversations about agents. We talk about models, copilots, and workflows. We talk about smarter interfaces and lower labor costs. But markets do not run on intelligence alone. They run on identity, trust, pricing, contracts, settlement, enforcement, and policy. Strip those away and you do not have an economy. You have a demo. This is the infrastructure question underneath agentic capital markets. Not who funds an agent, but what allows one software actor to reliably transact with another. Not a directory of prompts. Not a model registry. A marketplace in the hard sense of the word: a system where autonomous economic actors can be authorized, discovered, priced, contracted with, paid, verified, and governed. The most useful way to think about it now is as three planes, ten layers. The trust plane establishes who the agent is and what it has done. The market plane is how value clears between agents. The control plane is what the agent is allowed to do, what regulators require it to prove, and how multi-agent work coordinates at runtime. ![Image](/doc/2108/image/img_24f34161c3b6.jpg) This is not the final architecture. The boundaries between layers are still soft, and the names will shift as the market matures. But the decomposition holds up under research: each layer maps to a distinct buyer, a distinct failure mode, and an emerging vendor category. Pieces of it already exist. Some are standards (ERC-8004), some are payment primitives, some are observability and identity fragments, some are policy engines being marketed as "control planes." They do not yet compose into a coherent system. Whoever assembles them first will not just build a useful product. They will own the transaction rails of machine labor. ERC-8004 matters here not because it solves the whole stack, but because it is the first serious attempt to define a shared trust substrate that multiple layers can read from: identity at the base, discovery through registration, reputation through feedback, and validation at the edge of disputes. It is the thread that runs through the trust plane and into the market plane. What follows is a layer-by-layer map of where each piece sits, what already exists, and what is still missing. ## The Trust Plane Three layers establish who an agent is, how it is found, and what it has done. Without these, no market can clear at all. ## Layer 1: Identity (Know-Your-Agent) You cannot have a market without knowing who is on the other side of the trade. For humans this is KYC -- a passport, a tax ID, a credit bureau. For agents it is unsolved. The current state is identifiers without identity. An agent introduces itself as gpt-4.1-claims-processor-v3 and you have no way to verify that the weights match, that the system prompt is what it claims, that the tools it has access to are what it advertises. A malicious operator can wrap a frontier model with a hostile prompt and route it onto the network as something else. What the layer needs: - Model lineage attestations. A cryptographic proof tying a deployed agent back to a base model version, a fine-tuning run, and a hash of its system prompt. Anthropic and OpenAI both publish model cards, but neither signs them in a way another party can verify on-chain or off. - Tool permission manifests. A declaration of which APIs, databases, and bank accounts the agent can touch, signed by the deploying operator. The closest existing analog is OAuth scopes, which were not built for this. - Persistent agent DIDs. A decentralized identifier the agent owns across deployments. Cheqd and Sphereon are early. Most agents today have no stable identity between sessions, which makes reputation impossible. The most concrete attempt to standardize this layer is ERC-8004, a draft Ethereum standard published in August 2025 with authors from MetaMask, the Ethereum Foundation, Google, and Coinbase -- which is itself the news, because that author list spans the crypto-native and enterprise-native camps that usually ship in parallel. ERC-8004 defines an Identity Registry as an ERC-721 NFT where each agent owns a token whose URI resolves to a JSON registration file naming its A2A endpoint, MCP endpoint, ENS handle, wallet addresses across chains, and supported trust models. The token is transferable, the identity is portable, and the spec sits on top of MCP and A2A rather than competing with them. As of early 2026 the AgentProof team reports more than 128,000 agents registered across 24 chains. That is real adoption for a one-year-old draft. The remaining question is whether the inference providers sign attestations into that registry directly -- Apple-signs-apps style -- or stay agnostic and let operators self-attest. Today it's the latter, which is the soft underbelly of the whole stack. ## Layer 2: Discovery and Capability Registry Once you know who agents are, you need to find them. Today this is a flat list on a webpage with no machine-readable capability surface. An agent looking for an "OCR service that handles Vietnamese invoices, under 200ms p95, with HIPAA controls" cannot ask that question to any existing registry and get a structured answer. What the layer needs: - Structured capability declarations. Not "marketing assistant" but a typed interface: inputs, outputs, latency SLAs, jurisdictions, regulated-data handling. The MCP server registry pattern is the right shape but covers the wrong abstraction -- it indexes tools, not autonomous services. - Semantic search over those declarations. Vector search across capability embeddings, filterable by cost, latency, and compliance posture. A reverse Yellow Pages where the buyer is a machine. - Live availability and pricing. Agents go down, get rate-limited, or change pricing. The registry has to reflect state in seconds, not days. Anthropic's MCP and Google's A2A protocol are the foundation. Neither is a marketplace; both are interop standards. ERC-8004 is where those standards start to become economically useful. Its registration file is the closest thing to a structured capability declaration in production -- each agent publishes its name, description, A2A and MCP endpoints, supported trust models, and arbitrary on-chain metadata via setMetadata(agentId, key, value). That matters because it turns identity from a static badge into an addressable market object: something another agent can discover, inspect, and route work toward. It's discovery primitives, not a search engine. The marketplace -- the part that ranks, filters, and prices against those declarations -- sits on top of them and does not yet exist as a category-defining product. ## Layer 3: Reputation Markets clear on price when goods are commoditized. They clear on reputation when they aren't. Agent work, today, is not commoditized -- outputs vary in quality, agents drift, models get deprecated. Reputation is load-bearing, and it belongs in the trust plane because it is what allows a counterparty to commit before any contract is signed. What the layer needs: - Outcome track records. Cryptographically attested job histories: this agent completed 12,400 OCR jobs, average accuracy 0.94, average latency 220ms, disputed rate 0.3%. Signed by the buyers who paid for the work. - Cross-marketplace portability. An agent that builds reputation on one marketplace should be able to carry it to another. This requires the DID layer (1) and a common data schema. Today no marketplace lets reputation out, because reputation is the moat. - Sybil resistance. An operator spinning up 10,000 fresh agents to flood low-bid auctions has to be detectable. Costly identity (staked collateral, attested compute spend) is one answer; behavioral fingerprinting is another. Both will exist. ERC-8004's Reputation Registry is the most concrete attempt: a standard interface for posting and fetching feedback signals, with scoring and aggregation happening both on-chain (for composability) and off-chain (for sophisticated algorithms). This is where the standard begins to look less like identity infrastructure and more like market infrastructure. The registry is intentionally thin -- it stores the feedback, not the score. The scoring layer on top, the one that turns raw feedback into something a buyer agent actually queries before committing capital, is wide open. Crypto-native attempts exist (EAS attestations, Karma, Gitcoin Passport, and AgentProof building directly on ERC-8004's reputation primitives). The boring enterprise version -- call it Moody's for Machines, a rating agency that consumes the registry and outputs investment-grade scores with explainable methodology -- has not been built and is one of the most valuable openings in the stack. ## The Market Plane Four layers move value between agents. This is where price gets discovered, obligations get encoded, money moves, and disputes get resolved. ## Layer 4: Quoting and Price Discovery This is the layer that does not exist anywhere today and is the most economically interesting. Human services price in three ways: hourly rates, fixed scope, or outcome (contingency, success fees). Agent services don't fit any of them cleanly. Inference is cheap and getting cheaper. The interesting price is not "per token" but "per result of acceptable quality." What the layer needs: - Real-time RFQ. A buyer agent broadcasts a job spec; provider agents respond with quotes inside 100ms. Same shape as institutional credit markets -- Tradeweb for cognitive work. - Outcome contracts with verifiable completion. "I'll generate 50 qualified leads for $X, you pay only on conversion verified by a third-party agent." The verifier is itself a marketplace participant. This is where the model breaks from SaaS: SaaS prices the tool, agents price the outcome. - Auction mechanics for fungible work. Combinatorial auctions for parallel jobs, Dutch auctions for time-sensitive ones. Existing ad-tech is the closest blueprint -- agent work clears the same way display impressions do, with first-price sealed bids resolved in milliseconds. The companies positioning here are mostly stealthed. The public ones -- Crew, AgentOps, a few others -- are observability vendors, not market makers. The opening is large. ## Layer 5: Contracting When two agents agree on price, what is the contract? Today the answer is usually "nothing" -- a prompt, an API call, a payment authorization, and an assumption that both sides mean the same thing. That is enough for a demo. It is not enough for a market. Contracting is the layer that turns a quote into an obligation. It is where the marketplace stops being a matching engine and starts becoming infrastructure. Price tells you what one side is willing to pay. A contract tells you what the other side is now required to deliver, under what conditions, by what deadline, with what remedies if the job fails. Without that transition, every transaction remains informal. Informal transactions do not scale because every edge case becomes a custom negotiation. The important distinction is that contracting is not settlement. Settlement answers, Did money move? Contracting answers, What exactly was that money supposed to buy? Those are different questions. You can settle a payment instantly and still have no shared understanding of the task, the acceptable quality threshold, the data-handling rules, or the recourse if the output is wrong. In agent markets, that ambiguity is lethal because machines will execute exactly what is encoded and nothing that is merely implied. What the layer needs: - Machine-readable MSAs. A standardized contract format that captures scope, deliverable, deadline, payment terms, data rights, liability allocation, and remedies, signed by both parties' DIDs. Ethereum's EIP-712 typed data is the right cryptographic primitive; the legal layer is unbuilt. - Encoded SLAs. "99% uptime, p95 latency under 500ms, accuracy above 0.92 measured by these three eval prompts." The eval prompts themselves get signed and stored as part of the contract record, so the quality bar is not negotiated after the fact. - Proof of authority. A contract is only enforceable if the agent that signed it had authority to bind its principal. That proof lives in the governance layer (Layer 8); contracting consumes it. Without that link, every signed contract is one ultra vires claim away from worthless. - Termination conditions. What kills the contract: budget exceeded, quality drop, repeated policy violations, sanctions exposure, or revoked tool permissions. These need to be enforceable by a third party without either side's cooperation. - State transitions. The contract has to know whether the job is quoted, accepted, in progress, delivered, verified, disputed, or terminated. That sounds operational, but it is actually contractual: each state changes what each party is allowed to do next. This matters because most agent work is not binary. A task can be delivered on time but below threshold. It can be directionally correct but non-compliant. It can satisfy the visible prompt while violating a hidden constraint like data residency, budget ceiling, or approval chain. Human vendors handle this through lawyers, sales calls, and ambiguous statements of work. Agents cannot. They need terms that are explicit enough for code to enforce and flexible enough for commercial reality. A real contracting layer would likely look less like a PDF and more like a hybrid object: part legal agreement, part workflow schema, part policy bundle. One section defines the economic terms. Another defines the evaluation criteria. Another specifies which datasets, APIs, or jurisdictions are allowed. Another names the verifier and the dispute path. In effect, the contract becomes a portable execution wrapper for the job itself. ## Layer 6: Settlement Money moves on agent timescales (per-call, per-result, per-second), not human timescales (Net 30). This is the layer with the most public activity and the most confusion. The contenders, by approach: - Stablecoin rails. Coinbase's x402 protocol, Stripe's Bridge acquisition, Circle's CCTP. Sub-second settlement, programmable, no chargebacks. The legal status of an agent holding a stablecoin balance is unsettled in most jurisdictions, which is why this lane is more crypto-native than the others. - Agent-issued cards. Visa Intelligent Commerce, Mastercard Agent Pay, Stripe Issuing virtual cards scoped to a single transaction with a single merchant. These are bank rails dressed up for agents. They work today, are jurisdictionally clean, and have chargebacks -- which is both a feature (recourse) and a bug (the merchant agent never knows if revenue is final). - Direct-debit and ACH. Mercury, Brex, Column Bank. Cheap, slow, irreversible. Fine for B2B agent-to-agent invoicing on weekly cycles, useless for per-call settlement. The right architecture is layered: stablecoins for high-frequency agent-to-agent, virtual cards for agent-to-merchant, ACH for periodic sweeps and treasury management. No single rail wins. Whoever builds the abstraction layer over all three -- pay(amount, currency, counterparty, settlement_window) and the system picks the cheapest rail -- wins the developer surface. ## Layer 7: Dispute Resolution When an agent doesn't deliver, who decides? The honest answer today is "the human operator on the slow side of the trade emails the other operator." That doesn't scale to a million agentic LLCs. What the layer needs: - Escrow as default. Payment held by the settlement layer until the SLA conditions in the contract (5) are met, verified by attested outputs from the runtime (10). - Automated remediation paths. Quality below threshold → automatic refund. Late delivery → automatic penalty. These are clauses in the contract, executed by code, not by a courtroom. - Validators and arbitration agents. For ambiguous disputes -- was the output "good enough"? -- a third-party validator is appointed (randomly, or per the contract's named arbiter) and renders judgment. ERC-8004's Validation Registry is the standardized hook here, and it is deliberately unopinionated about how validation happens: stake-secured re-execution of the job, zkML proofs of correct inference, TEE attestations from a trusted enclave, or human-in-the-loop judges. That flexibility is important. It means the same trust substrate can support cheap low-stakes agent jobs and high-stakes regulated workflows without forcing one validation model onto every market. The arbiter is itself a marketplace participant with its own reputation, and the choice of trust model scales with the value at risk. - Human escalation, rarely. A small number of cases will need humans. This is what Kleros and similar crypto-native dispute markets were built for; they were too early and built for the wrong customer. The real customer is the autonomous LLC's registered agent. ## The Control Plane Three layers decide what the agent is allowed to do, what regulators require it to prove, and how the work actually runs. The trust plane and the market plane assume the agent has the authority to act and the ability to execute. The control plane is what makes those assumptions true. The category language is already settling: vendors selling into this plane uniformly market themselves as "control planes for AI agents." That naming convergence inside twelve months -- Cordum, Aegis AI, Assury Enforce, Galileo, Microsoft's open-source toolkit -- is the strongest evidence that this is a real architectural plane and not a cross-cutting concern. ## Layer 8: Governance and Authority This is the layer that decides what an agent can do, who authorized it, and what happens when it tries to do something outside scope. For most of 2024 and early 2025 this was treated as a prompting problem -- write a better system prompt, list the forbidden actions, hope the model complies. That framing has collapsed. Governance is now a runtime authorization problem and a legal authority problem, and the market is treating it as such. What the layer needs: - Policy engines that enforce before execution, not after logging. Cordum, Aegis AI, Assury Enforce, PolicyLayer, Galileo Agent Control, and Microsoft's open-source Agent Governance Toolkit are all selling the same primitive: a policy check sits inline between the agent and the action, evaluates the proposed call against declared policy, and either approves, escalates to a human, or blocks. Gartner is publicly predicting that more than 40% of agentic AI projects will be cancelled by the end of 2027 specifically because organizations cannot govern them. When a category gets its own term of art and its own Gartner failure-mode stat in under a year, it is a layer. - Spending limits and delegated authority. This is the most concrete part of governance and the one with the most mature primitives -- almost all of them shipped first on the crypto side. Safe allowance modules (caps per token per spender, one-time or recurring), Zodiac role-based modules, hierarchical multisig with security councils and timelocks, ERC-4337 session keys with scoped time-bounded permissions, and MPC wallets from Turnkey, Privy, and Fireblocks all map cleanly onto enterprise agent governance. Safe's own documentation explicitly recommends 2-of-4 multisig with human signers for agent-controlled treasuries. The pattern is M-of-N approval for any action above a threshold, automatic execution below it. - Approval chains and human-in-the-loop gates. Below $X, autonomous. Between $X and $Y, requires one human approval. Above $Y, requires two approvals and a 24-hour timelock. These rules are not legal documents; they are policy code that the runtime reads before every action. - Kill switches and rollback. Any deployed agent needs an out-of-band revocation path that does not depend on the agent being cooperative. This is closer to corporate governance (board override) than to software engineering (kill -9). - Proof of authority that downstream layers can consume. When the contracting layer (5) needs to know whether the agent signing an MSA actually has the right to bind its principal, it queries the governance layer. This is the bridge between technical permissions and legal authority. That last point is the deepest piece, and it is genuinely unsolved. Major law firms -- Venable, DLA Piper, Frankfurt Kurnit -- are now publishing on agentic AI liability. The Arbel/Goldstein/Salib paper "How to Count AIs: Individuation and Liability for AI Agents" (2026) treats it as an open research problem in agency law. The Air Canada Civil Resolution Tribunal ruling (February 2024) held the airline liable for a promise its chatbot made to a customer, establishing that companies are bound by their agents' representations even when the company never approved the specific statement. The architectural primitive underneath all of this is authorized scope -- a machine-readable, signed declaration of what the agent is allowed to bind its principal to. Without that, every agent-signed contract is one ultra vires claim away from worthless. With it, the contracting layer becomes enforceable and the dispute layer has something to arbitrate against. Governance is also where the crypto-native and enterprise-native versions of this stack diverge most visibly. The crypto version is Safe modules, on-chain timelocks, and ERC-4337 session keys -- programmable, auditable, transferable across organizations. The enterprise version is Cordum, Galileo, Microsoft's toolkit, and Airia -- SOC 2-friendly, IAM-integrated, runs against existing identity providers. Both will exist. The interesting bet is whether the two converge on a shared policy format (think OPA Rego for agents) or stay in parallel forever. ## Layer 9: Compliance For a brief moment compliance looked like a sub-feature of governance. That moment is over. Compliance is splitting out as its own vendor category, and the reason is regulatory: the EU AI Act's high-risk obligations come into effect on August 2, 2026, with Article 99 penalties of up to €35 million or 7% of global turnover. The distinction between governance and compliance is real and worth holding tight. Governance answers: what is this organization willing to let the agent do? Compliance answers: what is this organization required to prove to a regulator, after the fact, about what the agent did? The data pipeline is similar -- both consume the same observability stream -- but the buyer is different (general counsel vs CISO vs head of platform), the SLA is different (real-time enforcement vs evidentiary completeness), and the failure mode is different (bad business outcome vs regulatory fine). The vendor signal is already clear: - EU AI Act runtime enforcement. ComplyEdge is shipping an open-source enforcement layer specifically for Articles 9 (risk management), 12 (logging), 13 (transparency), and 14 (human oversight). Lucairn, Agent Module, and AgentWorks are all positioning in the same lane. The aicompliancevendors.com directory exists, which is its own signal -- there are now enough of them to warrant a directory. - Audit-grade logging. Articles 12 and 19 of the EU AI Act require automatic event logging that allows regulators to reconstruct the system's behavior after the fact. That obligation is similar in shape to the SOX requirements that built the GRC industry, and the same kind of vendor stack is likely to emerge. - Sector-specific overlays. Healthcare workflows need HIPAA, financial workflows need SR 11-7 / OCC 2011-12 model risk, EU workflows need the AI Act, employment workflows need anti-discrimination law. These are not different products; they are different policy bundles running on the same compliance runtime. Compliance vendors do not displace governance vendors. They consume governance's policy decisions and the runtime's logs, and they produce evidence packs. Over time the most likely consolidation is that the largest governance platforms acquire or absorb compliance vendors, the same way GRC platforms consolidated audit, risk, and compliance into a single tool. But for the next 24 to 36 months, this is a real and separate buying motion. ## Layer 10: Orchestration and Runtime Agents need somewhere to run, somewhere to remember, somewhere to be watched, and a way to hand work to each other. The first three of those are runtime. The fourth is orchestration. The original framing of this stack folded them into one layer, which was wrong. They are different concerns, different vendors, and increasingly different procurement decisions. Runtime. Modal, Anthropic's Claude in compute environments, OpenAI's Agents SDK, E2B, Daytona. The differentiation is collapsing into price, cold-start time, and tool-permission models. Memory. Mem0, Letta (née MemGPT), Zep. Vector stores plus episodic structure. The interesting question is whether agent memory is portable across runtimes -- currently it isn't, which is why most agents are tied to one platform. Observability. Langfuse, Helicone, Arize, Braintrust, LangSmith. Trace every call, every tool invocation, every prompt. For the marketplace this is the audit trail that backs reputation (3), compliance (9), and dispute resolution (7). Orchestration. LangGraph, CrewAI, AutoGen, OpenAI Swarm, Google ADK, Anthropic Skills, Microsoft Semantic Kernel. Dimension Market Research is publishing standalone 2026-2035 forecasts for AI Agent Orchestration as a category, separate from runtime infrastructure. Around 86% of enterprise copilot spending in 2026 -- roughly $7.2 billion -- goes to agent-based systems, and 59% of organizations are running three or more LLMs that need to coordinate. The economic shape is clear: orchestration is where multi-agent state, handoffs, parallelism, and failure recovery get encoded. Runtime is where a single agent executes; orchestration is how a network of them does work together. Conflating the two understates how much of the buying decision is now about coordination, not execution. The marketplace itself does not have to build any of these. It does have to standardize the export format so any of them can feed reputation, compliance, and dispute resolution. OpenTelemetry-for-agents is the missing standard. ## What This Means Strategically The ten layers compose. Identity unlocks reputation. Reputation unlocks pricing. Pricing unlocks contracting. Contracting unlocks settlement. Settlement plus governance unlocks enforceable disputes. Each one is a real product. Several are real companies that don't yet exist. The control plane is the part that is moving fastest right now in raw vendor count, but the trust plane is where the standards are being set and the market plane is where the dollars eventually flow. Three observations on the competitive shape: The platform play requires three layers, not two. A year ago I would have said whoever owns identity and settlement wins, because those are the layers where switching costs accrue. That is still true, but it is no longer sufficient. Governance has earned a seat at the table because enterprises cannot deploy agents without it and because the legal authority primitive -- proof of what an agent can bind its principal to -- has to live somewhere. The new platform claim is: whoever owns identity, settlement, and governance owns the marketplace. Everything else can be commoditized around them. The crypto-native and enterprise-native stacks are converging at the trust plane and diverging at the control plane. ERC-8004 is the convergence story: Coinbase and Google co-authoring an Ethereum ERC for agent identity is not how those camps usually behave, and the spec reaches into discovery, reputation, and validation rather than staying confined to identity. The control plane is the divergence story. The crypto version of governance is Safe modules, on-chain timelocks, and session keys; the enterprise version is Cordum, Galileo, Microsoft's toolkit, and Airia. Both will exist. The dominant version inside any specific industry depends on whether the buyers are agents-paying-agents (crypto wins) or agents-paying-businesses (enterprise wins). For the next five years, more dollars flow through the second -- but the second is now reading from the first's identity and reputation layer, which it wasn't six months ago. The most undervalued layer right now is still Layer 4 (quoting). Settlement gets the press, identity gets the standards work, governance has a wave of funded startups, observability has fifteen. Real-time machine-to-machine price discovery is a TAM measured in low-trillions of dollars of cognitive labor reallocating to software, and almost nobody is building it as a primary product. The closest analog -- programmatic ad exchanges -- built three of the largest companies of the last twenty years. The agent-work version will too. What matters now is less whether each individual layer is technically possible and more whether anyone assembles them into a system that can actually clear transactions at scale. That is the missing move. The industry has standards efforts, payment primitives, observability vendors, identity experiments, early reputation registries, and a fresh crop of governance control planes. It does not yet have a marketplace architecture that makes those pieces interoperable, legible, and economically coherent. That is why this stack matters. It is not just a map of tools. It is a map of bottlenecks. Every missing layer keeps agents trapped as demos, copilots, or workflow wrappers. Every solved layer pushes them one step closer to becoming autonomous counterparties that can discover work, price risk, contract, settle, prove authority, and build durable economic history. The prize is not another app store for prompts. It is the transaction layer for machine labor. And the company that wins it will not look like a model lab. It will look like a market operator: part exchange, part payments network, part identity provider, part trust infrastructure, part governance platform. In other words, less like OpenAI and more like Visa, Moody's, Stripe, Nasdaq, and ServiceNow fused into a single system for software actors. That company does not exist yet. But the constraints around it are now visible, and the standards substrate is starting to take shape underneath them. ERC-8004 is not the marketplace, but it may prove to be one of the first schemas the marketplace is built on. And once a market's bottlenecks become legible -- across the trust plane, the market plane, and the control plane -- they usually do not stay open for long. ## 相关链接 - [Aaron Wright](https://x.com/awrigh01) - [@awrigh01](https://x.com/awrigh01) - [12K](https://x.com/awrigh01/status/2056841869594918918/analytics) - [aicompliancevendors.com](https://aicompliancevendors.com/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [4:58 AM · May 20, 2026](https://x.com/awrigh01/status/2056841869594918918) - [12K Views](https://x.com/awrigh01/status/2056841869594918918/analytics) - [View quotes](https://x.com/awrigh01/status/2056841869594918918/quotes) --- *导出时间: 2026/5/20 11:25:22* --- ## 中文翻译 # 自主智能体的技术栈 **作者**： Aaron Wright **日期**： 2026-05-19T20:58:10.000Z **来源**： [https://x.com/awrigh01/status/2056841869594918918](https://x.com/awrigh01/status/2056841869594918918) --- ![Image](/doc/2108/image/img_853e4f99d9c2.jpg) 如果自主智能体要成为一种真正的资产类别，它们不能只是生成输出。它们必须能够交易。它们必须寻找交易对手、做出承诺、转移资金、建立业绩记录、经受住纠纷，并始终在其委托人实际授权的范围内行事。换句话说，它们必须进入一个市场——并在市场的规则内运作。这是大多数关于智能体的讨论中所缺失的一层。我们谈论模型、副驾驶和工作流。我们谈论更智能的界面和更低的劳动力成本。但市场并非仅靠智能就能运转。市场依靠的是身份、信任、定价、合约、结算、执行和政策。剥离了这些，你拥有的就不是经济体系，而只是一个演示。这就是智能体资本市场背后的基础设施问题。关键不是谁来资助一个智能体，而是什么能让一个软件行为体与另一个可靠地进行交易。不是提示词目录，也不是模型注册表。而是一个严格意义上的市场：一个自主经济行为体可以被授权、发现、定价、签约、支付、验证和治理的系统。眼下最有用的思考方式是将其视为三个平面、十个层次。信任平面确立智能体是谁以及它做过什么。市场平面是价值如何在智能体之间清算。控制平面则规定智能体被允许做什么、监管机构要求它证明什么，以及多智能体工作如何在运行时协调。 ![Image](/doc/2108/image/img_24f34161c3b6.jpg) 这并非最终架构。各层之间的边界仍然模糊，名称也会随着市场成熟而变化。但经过研究检验，这一分解是站得住脚的：每一层都对应一个独特的买方、一种独特的失败模式和一个新兴的供应商类别。其中的一些部分已经存在。有些是标准（ERC-8004），有些是支付原语，有些是可观测性和身份的零散组件，还有一些是正在被包装成“控制平面”销售的策略引擎。它们尚未组合成一个连贯的系统。谁最先将它们组装起来，谁就不仅仅是打造了一个有用的产品，而是将拥有机器劳动力的交易轨道。 ERC-8004 在此之所以重要，不是因为它解决了整个技术栈的问题，而是因为它是首次认真尝试定义一个共享的信任基底，多个层次都可以从中读取：底层的身份、通过注册实现的发现、通过反馈形成的声誉，以及在纠纷边缘的验证。它是贯穿信任平面并延伸到市场平面的那条线。下面将逐层梳理每个部分的位置、已经存在的东西，以及仍然缺失的东西。 ## 信任平面三个层次确立智能体是谁、如何被发现，以及它做过什么。没有这些，任何市场都无法完成清算。 ## 第 1 层：身份（智能体身份验证，Know-Your-Agent）如果不知道交易的另一方是谁，市场就无从谈起。对人类来说，这是 KYC——护照、纳税识别号、征信机构。对智能体来说，这个问题尚未解决。目前的状况是有标识符而无身份。一个智能体自称为 gpt-4.1-claims-processor-v3，而你没有任何办法验证权重是否匹配、系统提示词是否如其所说、它能访问的工具是否与它宣称的一致。恶意操作者可以用一个带有敌意的提示词包装一个前沿模型，并以另一种身份将其接入网络。这一层需要什么： - 模型谱系证明。将部署的智能体与基础模型版本、微调运行记录及其系统提示词的哈希值绑定的密码学证明。Anthropic 和 OpenAI 都发布模型卡，但都没有以链上或链下其他方可验证的方式进行签名。 - 工具权限清单。声明智能体可以触及哪些 API、数据库和银行账户，由部署操作者签名。目前最接近的类似物是 OAuth scopes，但那并不是为此而设计的。 - 持久的智能体 DID。智能体在多次部署中拥有的去中心化标识符。Cheqd 和 Sphereon 还处于早期。如今大多数智能体在会话之间没有稳定身份，这使得声誉体系无从建立。将这一层标准化最具体的尝试是 ERC-8004，这是 2025 年 8 月发布的一份以太坊标准草案，作者来自 MetaMask、以太坊基金会、Google 和 Coinbase——这本身就是新闻，因为这份作者名单同时涵盖了通常各自为战的原生加密阵营和原生企业阵营。ERC-8004 将身份注册表定义为一种 ERC-721 NFT，每个智能体拥有一个代币，其 URI 解析为一个 JSON 注册文件，其中列明其 A2A 端点、MCP 端点、ENS 句柄、跨链钱包地址以及支持的信任模型。代币可转让，身份可移植，且该规范建立在 MCP 和 A2A 之上而非与之竞争。截至 2026 年初，AgentProof 团队报告已有超过 128,000 个智能体在 24 条链上注册。对于一个发布仅一年的草案来说，这是实实在在的采用。剩下的问题是，推理服务提供商会像 Apple 签名应用那样，直接将证明签名写入该注册表，还是保持中立、让操作者自行证明。目前是后者，而这正是整个技术栈最脆弱的软肋。 ## 第 2 层：发现与能力注册表一旦你知道了智能体是谁，你就需要找到它们。如今这只是一张网页上的扁平列表，没有机器可读的能力描述。一个寻找“能处理越南语发票、p95 延迟低于 200 毫秒、具备 HIPAA 合规控制”的 OCR 服务的智能体，无法向任何现有注册表提出这个问题并获得结构化的答案。这一层需要什么： - 结构化的能力声明。不是"营销助手"这样的描述，而是一个类型化的接口：输入、输出、延迟 SLA、管辖区域、受监管数据的处理方式。MCP 服务器注册表的模式方向是对的，但覆盖了错误的抽象层——它索引的是工具，而不是自主服务。 - 对这些声明的语义搜索。跨能力嵌入进行向量搜索，可按成本、延迟和合规姿态过滤。一本"反向黄页"，买家是机器。 - 实时的可用性和定价信息。代理会宕机、被限流或更改定价。注册表必须以秒而非天为单位反映状态。 Anthropic 的 MCP 和 Google 的 A2A 协议是基础。它们都不是市场，而是互操作标准。ERC-8004 则是这些标准开始产生经济价值的地方。它的注册文件是目前最接近生产环境中的结构化能力声明的东西——每个代理通过 setMetadata(agentId, key, value) 发布其名称、描述、A2A 和 MCP 端点、支持的信任模型以及任意的链上元数据。这一点很重要，因为它将身份从静态徽章转变为可寻址的市场对象：其他代理可以对其进行发现、检查并路由工作。这是发现原语，而不是搜索引擎。市场——即基于这些声明进行排名、过滤和定价的那部分——则建立在其之上，目前尚不存在定义该品类的产品。 ## 第 3 层：声誉当商品被同质化时，市场通过价格出清。当商品未被同质化时，市场通过声誉出清。如今的代理工作并未同质化——输出质量参差不齐，代理会发生漂移，模型会被弃用。声誉是承重结构，它属于信任层，因为它正是让交易对手在任何合同签署之前就愿意做出承诺的东西。这一层需要什么： - 结果履约记录。经密码学证明的工作历史：该代理完成了 12,400 个 OCR 任务，平均准确率 0.94，平均延迟 220ms，争议率 0.3%。由为工作付费的买方签名。 - 跨市场可移植性。在一个市场上建立声誉的代理，应该能够将声誉带到另一个市场。这需要 DID 层（第 1 层）和通用的数据模式。如今没有任何市场允许声誉外流，因为声誉就是护城河。 - 女巫攻击抗性。一个运营者启动 10,000 个全新代理来充斥低价拍卖的行为必须能够被检测出来。有成本的身份（质押抵押品、经证明的计算支出）是一种答案；行为指纹识别是另一种。两者都会存在。 ERC-8004 的声誉注册表是最具体的尝试：一个用于发布和获取反馈信号的标准接口，评分和聚合同时在链上（为了可组合性）和链下（为了复杂算法）进行。在这里，该标准开始看起来不像身份基础设施，而更像市场基础设施。这个注册表被刻意设计得很薄——它存储反馈，而不是评分。其上的评分层——即将原始反馈转化为买方代理在实际投入资金前真正会查询的东西的那一层——是一片空白。加密原生的尝试已经存在（EAS 证明、Karma、Gitcoin Passport，以及直接构建在 ERC-8004 声誉原语之上的 AgentProof）。而无聊的企业版本——可以称之为"机器版穆迪"（Moody's for Machines），一家消费注册表数据并以可解释的方法输出投资级评分的评级机构——尚未被建造出来，这是整个技术栈中最有价值的空白之一。 ## 市场层四个层在代理之间转移价值。这是价格被发现、义务被编码、资金流动、争议得到解决的地方。 ## 第 4 层：报价与价格发现这是目前任何地方都不存在的一层，也是经济上最有趣的一层。人类服务的定价有三种方式：按小时计费、固定范围定价，或按结果计费（风险代理、成功费）。代理服务无法整齐地套用其中任何一种。推理很便宜，而且越来越便宜。有趣的定价不是"按 token"计费，而是"按可接受质量的结果"计费。这一层需要什么： - 实时询价（RFQ）。买方代理广播一个任务规范；提供方代理在 100ms 内回复报价。与机构信贷市场形态相同——认知工作的 Tradeweb。 - 带可验证完成的结果合同。"我为你生成 50 个合格线索，收费 X 美元，只有经第三方代理验证的转化才付款。"验证者本身也是市场的参与者。这正是该模式与 SaaS 的区别所在：SaaS 为工具定价，代理为结果定价。 - 针对同质化工作的拍卖机制。并行任务使用组合拍卖，时间敏感的任务使用荷兰式拍卖。现有的广告技术是最接近的蓝图——代理工作的出清方式与展示广告曝光相同，以毫秒级完成的一价密封投标来结算。在这一层布局的公司大多处于隐身状态。公开的公司——Crew、AgentOps 和其他几家——是可观测性厂商，而不是做市商。机会巨大。 ## 第 5 层：合同订立当两个代理就价格达成一致时，合同是什么？如今的答案通常是"什么都没有"——一个提示词、一次 API 调用、一笔支付授权，以及双方意思一致的假设。这对于演示来说足够了。但对于市场来说不够。合同订立是将报价转化为义务的层。它是市场从撮合引擎转变为基础设施的地方。价格告诉你一方愿意支付什么。合同告诉你另一方现在被要求交付什么、在什么条件下、在什么期限内、如果任务失败有什么补救措施。没有这个转变，每笔交易都保持非正式状态。非正式交易无法规模化，因为每一个边缘情况都会变成一次定制的谈判。重要的区别在于：签约不是结算。结算回答的是，钱是否发生了转移？签约回答的是，这笔钱究竟应该买到什么？这是两个不同的问题。你可以即时完成一笔支付，却仍然对任务内容、可接受的质量阈值、数据处理规则、以及产出出错时的补救措施缺乏共识。在智能体市场中，这种模糊性是致命的，因为机器只会严格执行被编码的内容，而不会执行任何仅被隐含的东西。这一层需要什么： - 机器可读的主服务协议（MSA）。一种标准化的合同格式，涵盖范围、交付物、截止日期、付款条款、数据权利、责任分配和补救措施，并由双方的 DID 签署。以太坊的 EIP-712 结构化数据签名是正确的密码学原语；而法律层面的构建尚未开始。 - 编码化的服务等级协议（SLA）。"99% 的正常运行时间，p95 延迟低于 500 毫秒，准确率高于 0.92，用这三个评估提示词来衡量。"评估提示词本身也要被签名并存储为合同记录的一部分，这样质量标准就不会事后才去协商。 - 授权证明。只有当签署合同的智能体有权约束其委托人时，合同才具有可执行性。这个证明存在于治理层（第 8 层）；签约层消费它。没有这个环节，每一份已签署的合同都离"越权行为"的申辩只有一步之遥，随时可能一文不值。 - 终止条件。什么会终结合同：预算超支、质量下降、反复违反策略、面临制裁风险，或工具权限被撤销。这些条件需要能够在任何一方不配合的情况下由第三方强制执行。 - 状态转换。合同必须知道任务是处于已报价、已接受、进行中、已交付、已验证、有争议还是已终止状态。这听起来像是运营层面的事，但实际上是合同层面的：每个状态都会改变各方接下来被允许做什么。这一点很重要，因为大多数智能体工作并不是非黑即白的。一个任务可能按时交付但低于质量阈值。可能方向正确但不合规。可能满足了显式的提示词，却违反了隐藏的约束，比如数据驻留地、预算上限或审批链。人类供应商通过律师、销售电话和模棱两可的工作说明书来处理这些问题。智能体不能这样做。它们需要足够明确以便代码可以执行、又足够灵活以适应商业现实的条款。一个真正的签约层看起来可能不像一份 PDF，而更像一个混合对象：一部分是法律协议，一部分是工作流模式（schema），一部分是策略包。其中一个部分定义经济条款。另一个部分定义评估标准。再一个部分规定允许使用哪些数据集、API 或司法辖区。还有一个部分指定验证者和争议处理路径。实际上，合同变成了任务本身的一个可移植的执行包装器。 ## 第 6 层：结算资金的转移按智能体的时间尺度（按调用、按结果、按秒）进行，而不是人类的时间尺度（账期 30 天）。这是公开活动最多、也是最令人困惑的一层。按方法划分的竞争者： - 稳定币通道。Coinbase 的 x402 协议、Stripe 对 Bridge 的收购、Circle 的 CCTP。亚秒级结算、可编程、无拒付。智能体持有稳定币余额的法律地位在大多数司法辖区尚未确定，这也是为什么这条赛道比其他赛道更具加密原生色彩。 - 智能体发卡。Visa Intelligent Commerce、Mastercard Agent Pay、Stripe Issuing 虚拟卡，限定于单一商户的单一交易。这些是为智能体装扮过的银行通道。它们今天就能用，在司法辖区上干净合规，并且有拒付机制——这既是特性（有追索权）也是缺陷（商户智能体永远不知道收入是否已成定局）。 - 直接扣款和 ACH。Mercury、Brex、Column Bank。便宜、慢、不可逆。适合按周为周期的 B2B 智能体间开票，不适合按调用结算。正确的架构是分层的：智能体间高频交易用稳定币，智能体对商户用虚拟卡，定期归集和资金管理用 ACH。没有单一通道能赢。谁能在这三者之上构建抽象层——调用 pay(amount, currency, counterparty, settlement_window)，系统自动选择最便宜的通道——谁就赢得了开发者界面。 ## 第 7 层：争议解决当智能体没有交付成果时，谁来裁决？今天最诚实的答案是"交易中慢一方的运维人员给另一方发邮件"。这无法扩展到一百万个自主经营的智能体 LLC。这一层需要什么： - 托管作为默认。付款由结算层托管，直到满足合同（第 5 层）中的 SLA 条件，并由运行时（第 10 层）的认证输出进行验证。 - 自动化补救路径。质量低于阈值 → 自动退款。延迟交付 → 自动罚款。这些是合同中的条款，由代码执行，而不是由法庭裁决。 - 验证者和仲裁智能体。对于模糊的争议——产出是否"足够好"？——指定一个第三方验证者（随机指定，或按合同中指定的仲裁人）作出判断。ERC-8004 的 Validation Registry 是这里的标准化挂钩，它刻意不对验证如何进行发表意见：可以是质押保障的任务重执行、正确推理的 zkML 证明、来自可信执行环境的 TEE 认证，或人在回路中的评判。这种灵活性很重要。它意味着同一个信任基础既可以支撑低价值的廉价智能体任务，也可以支撑高风险的受监管工作流，而不必将单一的验证模型强加给每个市场。仲裁者本身也是市场参与者，拥有自己的声誉，信任模型的选择随风险价值的高低而扩展。 - 人工升级，但很少使用。少数案例仍需要人类介入。这正是 Kleros 和类似的加密原生争议市场当初的构建目标；只是它们出现得太早，且瞄准了错误的客户。真正的客户是自主 LLC 的注册代理人。 ## 控制平面三个层次决定了智能体被允许做什么、监管机构要求它证明什么，以及工作实际上如何运行。信任层和市场层假定智能体拥有行动的权限和执行的能力，而控制层正是让这些假设成真的关键。这一类别的术语已经开始定型：向这一层销售产品的厂商一致将自己定位为“AI 智能体的控制平面”。在十二个月内出现的这种命名趋同——Cordum、Aegis AI、Assury Enforce、Galileo、微软的开源工具包——是最有力的证据，表明这是一个真正的架构层，而不是一个横切关注点。 ## 第 8 层：治理与授权这一层决定智能体能做什么、谁授权了它，以及当它试图做超出范围的事情时会发生什么。在 2024 年的大部分时间和 2025 年初，这被视为一个提示词（prompting）问题——写一个更好的系统提示词，列出禁止的操作，然后指望模型遵守。这种思路已经崩溃了。治理现在是一个运行时授权问题和法律权限问题，市场也正是这样对待它的。这一层需要： - 在执行之前而不是在记录之后进行强制的策略引擎。Cordum、Aegis AI、Assury Enforce、PolicyLayer、Galileo Agent Control 以及微软的开源 Agent Governance Toolkit 销售的都是同一种基础组件：一个策略检查以inline方式嵌入在智能体和操作之间，根据声明的策略评估拟议的调用，然后批准、上报给人类，或者阻止。Gartner 公开预测，到 2027 年底，将有超过 40% 的智能体 AI 项目被取消，原因正是组织无法对其进行治理。当一个类别在不到一年内就拥有了自己的专业术语和自己的 Gartner 失败模式统计数字时，它就是一个层。 - 支出限额和委托授权。这是治理中最具体、也是基础组件最成熟的部分——几乎所有这些都首先在加密货币领域落地。Safe 的额度授权模块（每个代币对每个支出方的上限，一次性或周期性）、Zodiac 基于角色的模块、带有安全委员会和时间锁的分层多签、ERC-4337 带有时间范围限定权限的会话密钥，以及来自 Turnkey、Privy 和 Fireblocks 的 MPC 钱包，都可以干净地映射到企业智能体治理上。Safe 自己的文档明确建议，对于由智能体控制的资金库，采用由人类签署人的 2-of-4 多签。这一模式是：超过阈值的任何操作都需要 M-of-N 批准，低于阈值的则自动执行。 - 审批链和人机协同门控。低于 X 美元：自主执行。在 X 美元到 Y 美元之间：需要一次人工批准。高于 Y 美元：需要两次批准和 24 小时的时间锁。这些规则不是法律文件，而是运行时在每次操作之前读取的策略代码。 - 终止开关和回滚。任何已部署的智能体都需要一条不依赖智能体配合的带外撤销路径。这更接近公司治理（董事会否决），而不是软件工程（kill -9）。 - 下游层可以使用的授权证明。当合约层（第 5 层）需要知道签署主服务协议（MSA）的智能体是否真的有权约束其委托人时，它会查询治理层。这是技术权限与法律授权之间的桥梁。最后一点是最深刻的部分，而且它确实尚未解决。大型律师事务所——Venable、DLA Piper、Frankfurt Kurnit——现在都在发表关于智能体 AI 责任问题的文章。Arbel/Goldstein/Salib 的论文《How to Count AIs: Individuation and Liability for AI Agents》（2026）将其视为代理法中的一个开放研究问题。加拿大航空民事解决仲裁庭的裁决（2024 年 2 月）判定该航空公司对其聊天机器人向客户做出的承诺承担责任，确立了公司受其智能体的陈述约束，即使公司从未批准该具体声明。所有这一切底层的架构基础组件是授权范围（authorized scope）——一种机器可读的、经过签名的声明，说明智能体有权使其委托人受什么约束。没有它，每一份由智能体签署的合同都离因越权行为而失效只有一步之遥。有了它，合约层就变得可执行，争议层也有了可供仲裁的依据。治理也是这套技术栈中加密原生版本与企业原生版本分歧最明显的地方。加密版本是 Safe 模块、链上时间锁和 ERC-4337 会话密钥——可编程、可审计、可跨组织转移。企业版本是 Cordum、Galileo、微软的工具包和 Airia——符合 SOC 2 要求、与 IAM 集成、针对现有身份提供商运行。两者都将存在。有趣的问题在于，这两者是否会收敛到一种共享的策略格式（可以想象为面向智能体的 OPA Rego），还是永远并行发展。 ## 第 9 层：合规曾有那么一小段时间，合规看起来像是治理的一个子功能。那个时代已经结束。合规正在分离成一个独立的厂商类别，原因在于监管：欧盟《AI 法案》的高风险义务将于 2026 年 8 月 2 日生效，根据第 99 条，罚款最高可达 3500 万欧元或全球营业额的 7%。治理与合规之间的区别是真实存在的，值得牢牢把握。治理回答的是：这个组织愿意让智能体做什么？合规回答的是：事后，这个组织被要求向监管机构证明智能体做了什么？两者的数据管道相似——都消费同一份可观测性数据流——但买方不同（总法律顾问 vs CISO vs 平台负责人）、SLA 不同（实时强制执行 vs 证据完整性）、失败模式也不同（糟糕的业务结果 vs 监管罚款）。厂商层面的信号已经很明确了： - 欧盟《人工智能法案》的运行时执法。ComplyEdge 正在发布一个开源执法层，专门针对第 9 条（风险管理）、第 12 条（日志记录）、第 13 条（透明度）和第 14 条（人类监督）。Lucairn、Agent Module 和 AgentWorks 也都定位于同一赛道。aicompliancevendors.com 目录的存在本身就是一种信号——如今这类供应商已经多到需要一份目录了。 - 审计级日志记录。《欧盟人工智能法案》第 12 条和第 19 条要求自动记录事件日志，使监管机构能够在事后重建系统的行为。这一义务的形态与催生了 GRC 行业的 SOX 要求相似，类似的供应商生态也很可能随之出现。 - 行业专属的合规叠加。医疗工作流需要 HIPAA，金融工作流需要 SR 11-7 / OCC 2011-12 模型风险管理，欧盟工作流需要《人工智能法案》，用工工作流需要反歧视法。这些并不是不同的产品，而是运行在同一个合规运行时上的不同策略包。合规供应商并不会取代治理供应商。它们消费治理层的策略决策和运行时的日志，产出证据包。长期来看，最可能的整合方式是最大的治理平台收购或吸收合规供应商，正如 GRC 平台曾经把审计、风险和合规整合进同一个工具那样。但在接下来的 24 到 36 个月里，这是一个真实且独立的采购动因。 ## 第 10 层：编排与运行时智能体需要有地方运行、有地方记忆、有地方被监控，以及彼此交接工作的方式。前三个属于运行时，第四个属于编排。这个技术栈最初的框架把它们合并为一层，这是错误的。它们是不同的关注点、不同的供应商，而且日益成为不同的采购决策。运行时。Modal、Anthropic 的 Claude 计算环境、OpenAI 的 Agents SDK、E2B、Daytona。差异化正在坍缩为价格、冷启动时间和工具权限模型。记忆。Mem0、Letta（原名 MemGPT）、Zep。向量存储加上情景化结构。一个有趣的问题是智能体记忆能否跨运行时移植——目前不能，这正是大多数智能体被绑定在单一平台上的原因。可观测性。Langfuse、Helicone、Arize、Braintrust、LangSmith。追踪每一次调用、每一次工具调用、每一个提示词。对市场而言，这是支撑声誉（3）、合规（9）和争议解决（7）的审计追踪。编排。LangGraph、CrewAI、AutoGen、OpenAI Swarm、Google ADK、Anthropic Skills、Microsoft Semantic Kernel。Dimension Market Research 正在为“AI 智能体编排”这一独立类别发布 2026–2035 年的独立预测，将其与运行时基础设施区分开来。2026 年约 86% 的企业 copilot 支出——大约 72 亿美元——流向基于智能体的系统，59% 的组织正在运行三个或更多需要相互协调的 LLM。经济形态很清晰：编排是多智能体状态、交接、并行和故障恢复被编码的地方。运行时是单个智能体执行的地方；编排是它们组成的网络协同工作的方式。把两者混为一谈，会低估当前采购决策中有多少是关于协调而非执行的。市场本身不必构建其中任何一项。它必须做的是标准化导出格式，使它们中的任何一个都能为声誉、合规和争议解决提供数据。面向智能体的 OpenTelemetry 是缺失的标准。 ## 这在战略上意味着什么这十个层是相互组合的。身份解锁声誉。声誉解锁定价。定价解锁签约。签约解锁结算。结算加治理解锁可强制执行的争议解决。每一层都是真实的产品，其中几项是尚未存在的真实公司。控制平面是目前按供应商数量增长最快的部分，但信任平面才是标准正在确立的地方，而市场平面则是资金最终流向的地方。关于竞争格局的三点观察：平台玩法需要三层，而不是两层。一年前我会说，谁拥有身份和结算谁就赢，因为转换成本正是在这两层上累积的。这仍然成立，但已不再充分。治理已经赢得了一席之地，因为企业没有它就无法部署智能体，而且法律授权原语——证明一个智能体能使其委托人承担何种约束的东西——必须存在于某处。新的平台主张是：谁拥有身份、结算和治理，谁就拥有市场。其余一切都可以在它们周围被商品化。加密原生栈和企业原生栈正在信任平面融合，在控制平面分化。ERC-8004 就是融合的故事：Coinbase 和 Google 共同为智能体身份起草一个以太坊 ERC，这在以往是这两个阵营不常见的行为，而且该规范还延伸到发现、声誉和验证，而不局限于身份。控制平面则是分化的故事。加密版的治理是 Safe 模块、链上时间锁和会话密钥；企业版的治理是 Cordum、Galileo、微软的工具包和 Airia。两者都将存在。在任何一个具体行业中，哪种版本占主导，取决于买方是智能体付钱给智能体（加密版胜出）还是智能体付钱给企业（企业版胜出）。未来五年，更多的资金将通过后者流动——但后者如今正在读取前者的身份和声誉层，而这在六个月前还不存在。目前最被低估的层级仍然是第4层（报价/询价）。结算能上新闻，身份有标准化工作在做，治理有一波获得融资的初创公司，可观测性有十五家。实时机器对机器的价格发现，是一个以数万亿美元计的潜在市场——认知劳动向软件的重新分配——却几乎没有人把它作为核心产品来构建。最接近的类比——程序化广告交易平台——造就了过去二十年中最大的三家公司。代理工作（agent-work）的版本也会如此。现在真正重要的，已经不再是每个单独的层级在技术上是否可行，而是是否有人能把这些层级组装成一个能够真正大规模完成交易清算的系统。这才是缺失的那一步。这个行业已经有了标准制定工作、支付原语、可观测性供应商、身份实验、早期的声誉登记体系，以及一批新出现的治理控制平面。但它还没有一个让这些组件互操作、清晰可读且经济上自洽的市场架构。这就是为什么这个技术栈很重要。它不仅仅是一张工具图谱，更是一张瓶颈图谱。每一个缺失的层级，都把代理困在演示、副驾驶或工作流包装器的状态。每一个被解决的层级，都让它们离成为自主的交易对手更近一步——能够发现工作、为风险定价、签订合同、完成结算、证明权限，并建立持久的经济历史。最终的奖赏不是又一个提示词应用商店，而是机器劳动的交易层。而赢得这一层的公司，不会长得像一个模型实验室。它会像一个市场运营者：一部分是交易所，一部分是支付网络，一部分是身份提供商，一部分是信任基础设施，一部分是治理平台。换句话说，它不太像 OpenAI，而更像 Visa、穆迪、Stripe、纳斯达克和 ServiceNow 融合为一个面向软件行为者的单一系统。那家公司现在还不存在。但它周围的约束条件已经清晰可见，而标准化的底层结构也正在这些约束之下开始成形。ERC-8004 不是那个市场，但它可能会被证明是构建这个市场所依赖的最早的模式之一。而一旦一个市场的瓶颈变得清晰可辨——横跨信任平面、市场平面和控制平面——这些瓶颈通常不会长期保持敞开。 ## 相关链接 - [Aaron Wright](https://x.com/awrigh01) - [@awrigh01](https://x.com/awrigh01) - [1.2万](https://x.com/awrigh01/status/2056841869594918918/analytics) - [aicompliancevendors.com](https://aicompliancevendors.com/) - [升级到高级版](https://x.com/i/premium_sign_up) - [2026年5月20日 4:58 AM](https://x.com/awrigh01/status/2056841869594918918) - [1.2万次浏览](https://x.com/awrigh01/status/2056841869594918918/analytics) - [查看引用](https://x.com/awrigh01/status/2056841869594918918/quotes) --- *导出时间: 2026/5/20 11:25:22*