自主智能体的技术栈：实现市场化交易的信任、市场与控制平面 ✍ Aaron Wright🕐 2026-05-20📦 31.2 KB 🟢 已读 𝕏 文章列表 文章探讨了自主智能体从生成式工具转变为真正资产类别的关键技术堆栈。作者指出，智能体若要进入市场并有效交易，必须建立超越单纯“智能”的基础设施。文章提出了由信任平面（身份、发现、声誉）、市场平面（定价、结算、流动性）和控制平面（授权、合规、协调）构成的十层架构。文中重点分析了 ERC-8004 标准在建立链上身份和互操作性方面的作用，并详细阐述了身份验证、能力注册和声誉追踪这三个信任层级目前存在的缺失与未来的解决方案。 Autonomous AgentsERC-8004BlockchainInfrastructureMarket DesignIdentityReputation SystemA2A Protocol # 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) ---  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.  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) ---  如果自主智能代理要成为一种真正的资产类别，它们就不能仅仅生成输出。它们必须进行交易。它们必须找到交易对手，做出承诺，转移资金，建立业绩记录，在纠纷中存活下来，并始终保持在委托人实际授权的范围内。换句话说，它们必须进入市场——并在市场规则内运作。 这是大多数关于代理的讨论中缺失的一环。我们谈论模型、副驾驶和工作流。我们谈论更智能的界面和更低的劳动力成本。但市场不仅仅靠智能运行。它们依靠身份、信任、定价、合约、结算、执行和政策运行。剥离了这些，你拥有的不是一个经济体，而只是一个演示。 这是代理资本市场底层的基础设施问题。不是谁来资助代理，而是什么允许一个软件行为者与另一个可靠地进行交易。不是提示词目录。不是模型注册表。而是这个词的硬核意义上的市场：一个系统，自主的经济行为者可以在其中被授权、被发现、被定价、签订合同、支付、验证和治理。 目前思考这个问题最有用的方法是将其分为三个平面、十层。信任平面确立了代理是谁以及它做了什么。市场平面是价值如何在代理之间清算。控制平面是代理被允许做什么，监管机构要求它证明什么，以及多代理工作在运行时如何协调。  这不是最终的架构。各层之间的界限仍然模糊，随着市场的成熟，名称也会发生变化。但这种分解在研究中站得住脚：每一层都对应一个不同的买家、一种不同的失败模式和一个新兴的供应商类别。其中的某些部分已经存在。有些是标准（ERC-8004），有些是支付原语，有些是可观测性和身份片段，还有一些是作为“控制平面”营销的策略引擎。它们尚未组合成一个连贯的系统。首先将它们组装起来的人，不仅仅是构建了一个有用的产品。他们将拥有机器劳动的交易轨道。 ERC-8004 之所以重要，不是因为它解决了整个堆栈，而是因为它是首次严肃尝试定义一个多层可以读取的共享信任底层：基础身份、通过注册发现的身份、通过反馈获得的声誉，以及在纠纷边缘的验证。它是贯穿信任平面并进入市场平面的线索。 以下是对每一部分的定位、已存在的内容以及仍然缺失的内容的逐层梳理。 ## 信任平面 三个层面确立了代理是谁、如何被发现以及它做了什么。没有这些，任何市场都无法清算。 ## 第1层：身份（了解你的代理/Know-Your-Agent） 如果你不知道交易对手是谁，就不可能有市场。对于人类来说，这是 KYC（了解你的客户）——护照、税务 ID、信用局。对于代理来说，这尚未解决。 目前的状态是只有标识符而没有身份。一个代理自我介绍为 gpt-4.1-claims-processor-v3，而你无法验证权重是否匹配，系统提示词是否如其声称的那样，它可以访问的工具是否如其所宣传的那样。恶意操作员可以用敌对的提示词包装一个前沿模型，并将其作为其他东西路由到网络上。 该层需要什么： - **模型谱系证明。** 一种加密证明，将部署的代理联系回基础模型版本、微调运行及其系统提示词的哈希值。Anthropic 和 OpenAI 都发布模型卡片，但都没有以另一方可以链上或链下验证的方式对它们进行签名。 - **工具权限清单。** 一份声明，说明代理可以接触哪些 API、数据库和银行账户，由部署操作员签名。最接近的现有类似物是 OAuth 作用域，但这并非为此构建。 - **持久的代理 DIDs。** 代理在跨部署中拥有的去中心化标识符。Cheqd 和 Sphereon 处于早期阶段。大多数代理今天在会话之间没有稳定的身份，这使得声誉变得不可能。 标准化该层的最具体尝试是 ERC-8004，这是一份于 2025 年 8 月发布的以太坊草案标准，作者来自 MetaMask、以太坊基金会、谷歌和 Coinbase——这本身就是一个新闻，因为这份作者名单跨越了通常并行交付的原生加密阵营和原生企业阵营。ERC-8004 将身份注册表定义为一个 ERC-721 NFT，其中每个代理拥有一个代币，其 URI 解析为一个 JSON 注册文件，命名其 A2A 端点、MCP 端点、ENS 句柄、跨链钱包地址和支持的信任模型。代币是可转让的，身份是可移植的，并且该规范位于 MCP 和 A2A 之上，而不是与它们竞争。截至 2026 年初，AgentProof 团队报告在 24 条链上注册了超过 128,000 个代理。对于一个一年前的草案来说，这是真正的采用。剩下的问题是推理提供商是否直接向该注册表签署证明——像 Apple 签名应用程序那样——还是保持中立并让操作员自我证明。今天是后者，这是整个堆栈的薄弱环节。 ## 第2层：发现与能力注册表 一旦你知道代理是谁，你需要找到它们。今天，这是网页上的一个扁平列表，没有机器可读的能力表面。一个寻找“处理越南发票、p95 延迟低于 200ms、具有 HIPAA 控制的 OCR 服务”的代理，无法向任何现有的注册表提出该问题并获得结构化的答案。 该层需要什么： - **结构化能力声明。** 不是“营销助手”，而是一个类型化接口：输入、输出、延迟 SLA、司法管辖区、受监管数据处理。MCP 服务器注册表模式的形状是对的，但覆盖的抽象层次错了——它索引的是工具，而不是自主服务。 - **针对这些声明的语义搜索。** 跨能力嵌入的向量搜索，可按成本、延迟和合规姿态进行过滤。一种反向黄页，其中买家是机器。 - **实时可用性和定价。** 代理会宕机、受到速率限制或更改定价。注册表必须在几秒钟内反映状态，而不是几天。 Anthropic 的 MCP 和谷歌的 A2A 协议是基础。两者都不是市场；都是互操作性标准。ERC-8004 是这些标准开始变得具有经济用途的地方。它的注册文件是生产中最接近结构化能力声明的东西——每个代理发布其名称、描述、A2A 和 MCP 端点、支持的信任模型，以及通过 setMetadata(agentId, key, value) 发布的任意链上元数据。这很重要，因为它将身份从静态徽章变成了可寻址的市场对象：其他代理可以发现、检查并路由工作的对象。它是发现原语，而不是搜索引擎。市场——即对这些声明进行排名、过滤和定价的部分——位于它们之上，尚未作为一个定义类别产品存在。 ## 第3层：声誉 当商品被商品化时，市场通过价格出清。当商品未被商品化时，市场通过声誉出清。今天的代理工作未被商品化——输出质量参差不齐，代理会漂移，模型会被弃用。声誉是承载负荷的，它属于信任平面，因为它允许交易对手在签署任何合同之前做出承诺。 该层需要什么： - **结果追踪记录。** 经过加密证明的工作历史：该代理完成了 12,400 个 OCR 工作，平均准确率 0.94，平均延迟 220ms，争议率 0.3%。由为工作付款的买家签名。 - **跨市场可移植性。** 在一个市场上建立声誉的代理应该能够将其带到另一个市场。这需要 DID 层（第1层）和一个通用的数据模式。今天没有市场允许声誉流出，因为声誉是护城河。 - **女巫抵抗。** 一个操作员启动 10,000 个新代理以淹没低价拍卖必须是可检测的。有成本的身份（质押抵押品、证明计算支出）是一个答案；行为指纹是另一个。两者都将存在。 ERC-8004 的声誉注册表是最具体的尝试：一个用于发布和获取反馈信号的标准接口，评分和聚合发生在链上（为了可组合性）和链下（为了复杂的算法）。这正是该标准开始看起来更像市场基础设施而不是身份基础设施的地方。注册表有意做得单薄——它存储反馈，而不是分数。位于顶部的评分层——即将原始反馈转化为买家代理在投入资本之前实际查询的东西——是一片广阔的开放地带。存在原生加密的尝试（EAS 证明、Karma、Gitcoin Passport，以及直接基于 ERC-8004 声誉原语构建的 AgentProof）。无聊的企业版本——可以称之为机器版的穆迪，一家消耗注册表并输出具有可解释方法论的投资级评分的评级机构——尚未建成，是堆栈中最有价值的 openings 之一。 ## 市场平面 四层在代理之间转移价值。这是价格被发现、义务被编码、资金移动和纠纷得到解决的地方。 ## 第4层：报价与价格发现 这是目前任何地方都不存在的一层，也是经济上最有趣的一层。 人类服务有三种定价方式：小时费率、固定范围或结果（或有费用、成功费）。代理服务并不完全适合其中任何一种。推理很便宜，而且越来越便宜。有趣的价格不是“每个 Token”，而是“具有可接受质量的结果”。 该层需要什么： - **实时 RFQ（询价）。** 买家代理广播工作规范；提供商代理在 100ms 内回复报价。形状与机构信贷市场相同——认知工作的 Tradeweb。 - **具有可验证完成度的结果合约。** “我将为 X 美元生成 50 个合格线索，你只需在第三方代理验证转化后付款。”验证者本身就是市场参与者。这就是模型与 SaaS 分道扬镳的地方：SaaS 为工具定价，代理为结果定价。 - **同质化工作的拍卖机制。** 用于并行工作的组合拍卖，用于时间敏感工作的荷兰拍卖。现有的广告技术是最接近的蓝图——代理工作的出清方式与展示印象相同，通过毫秒内解决的第一价格密封投标。 在这个领域定位的公司大多是隐形的。公开的公司——Crew、AgentOps 和其他几家——是可观测性供应商，而不是做市商。这个机会很大。 ## 第5层：合约（Contracting） 当两个代理就价格达成一致时，合约是什么？今天的答案通常是“什么也没有”——一个提示词、一个 API 调用、一个支付授权，以及假设双方的意思是一致的。这对于演示来说足够了。但对于市场来说是不够的。 合约是将报价转化为义务的一层。这是市场停止成为匹配引擎并开始成为基础设施的地方。价格告诉你一方愿意支付什么。合约告诉你另一方现在必须交付什么，在什么条件下，在什么截止日期前，以及如果工作失败有什么补救措施。没有这种转变，每笔交易仍然是非正式的。非正式交易无法扩展，因为每个边缘情况都会变成一场自定义谈判。 重要的区别在于，合约不是结算。结算回答的是，钱动了吗？合约回答的是，这笔钱到底应该买什么？这是不同的问题。你可以立即结算付款，但仍然对任务、可接受的质量阈值、数据处理规则或输出错误的补救措施没有共同的理解。在代理市场中，这种模糊性是致命的，因为机器将精确执行编码的内容，而不会执行任何仅仅是暗示的内容。 该层需要什么： - **机器可读的 MSA（主服务协议）。** 一种标准化的合约格式，捕获范围、交付成果、截止日期、付款条款、数据权利、责任分配和补救措施，由双方的 DID 签署。以太坊的 EIP-712 类型数据是正确的加密原语；法律层尚未建立。 - **编码的 SLA。** “99% 正常运行时间，p95 延迟低于 500ms，通过这三个评估提示词测量的准确率高于 0.92。”评估提示词本身被签名并存储为合约记录的一部分，因此质量门槛不是事后谈判的。 - **权限证明。** 只有在签署合约的代理有权约束其委托人时，合约才是可执行的。该证明存在于治理层（第8层）；合约层消费它。没有那个链接，每一份签署的合约都可能因为一项越权主张而变得一文不值。 - **终止条件。** 什么会终止合约：超出预算、质量下降、重复违反政策、制裁暴露或撤销工具权限。这些需要由第三方强制执行，而无需任何一方的合作。 - **状态转换。** 合约必须知道工作是已报价、已接受、进行中、已交付、已验证、有争议还是已终止。这听起来是操作性的，但实际上是合同性的：每种状态改变了每一方接下来被允许做的事情。 这很重要，因为大多数代理工作并不是二元的。任务可以按时交付但低于门槛。它在方向上可能是正确的，但不符合规定。它可以满足可见的提示词，同时违反隐藏的约束，如数据驻留、预算上限或审批链。人类供应商通过律师、销售电话和模糊的工作说明来处理这个问题。代理不能。它们需要足够明确以供代码执行，又足够灵活以适应商业现实的条款。 一个真正的合约层看起来可能不像 PDF，而更像一个混合对象：部分是法律协议，部分是工作流模式，部分是策略包。一部分定义经济条款。另一部分定义评估标准。另一部分指定允许哪些数据集、API 或司法管辖区。另一部分命名验证者和争议路径。实际上，合约变成了工作本身的可移植执行包装器。 ## 第6层：结算 资金在代理的时间尺度（每次调用、每个结果、每秒）上移动，而不是人类的时间尺度（Net 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层：Disp
构 构建递归智能体系统：扩展 Composer 训练规模 本文介绍了 Cursor 如何构建一个包含数千个 Agent 的递归系统，以加速 Composer 模型的训练。系统通过主 Agent 管理子 Agent 的“健康”状态，实现并行实验的自动化监控与故障修复。该架构将研究员的效能提升了数量级，使大量计算资源能像企业组织一样协同工作。 技术 › Agent ✍ Lee Robinson🕐 2026-06-14 智能体多Agent系统模型训练自动化运维大规模并行人工智能机器学习DevOpsInfrastructureCursor
最 最重要的 AI 创业领域不是 Agent，而是 AI Memory 本文探讨了 AI 领域被忽视的一环：记忆。文章指出，GBrain 正致力于构建持久的认知层，通过自动建立知识图谱和梦境循环维护，让 AI 拥有持久记忆和关系感知。作者认为，未来的 AI 竞争优势将属于那些能积累上下文和理解关系的系统，而不仅仅是智能体本身。 技术 › LLM ✍ Nainsi Dwivedi🕐 2026-05-30 AIMemoryGBrainAgentInfrastructureKnowledge GraphCognition
C CZ入场，未来趋势，Coinbase、Binance、OKX抢着给AI Agent发身份证这件事到底意味着什么？ 文章深入探讨了AI Agent经济中“身份认证”的核心难题。目前存在平台中心化（如Visa、支付宝）与区块链去中心化（如以太坊ERC-8004、x402协议）两条路径。作者分析了Coinbase、Binance等巨头在Agent支付与身份基础设施上的布局，指出Agent将独立完成交易与支付，并可能形成新的社会阶级。文章最后反思了该赛道面临的虚假繁荣与法律监管空白。 投资 › 加密货币 ✍ AI最严厉的父亲🕐 2026-05-17 AI AgentWeb3加密货币区块链身份认证x402ERC-8004Coinbase支付协议投资趋势
A AI Agents Have No Memory for Failure. So We Gave Them One. 本文指出 88% 的 AI Agent 无法投入生产，主要原因是它们缺乏记忆，无法从重复的失败中学习。作者开源了一款名为 Helix 的自愈运行时，通过引入“Gene Map”机制，让 Agent 能像拥有免疫系统一样，在毫秒级内利用已验证的修复方案解决常规错误，从而大幅降低诊断成本和延迟。 技术 › Agent ✍ Nicholas🕐 2026-04-15 AI AgentHelixSelf-healingInfrastructureOpen SourceLLMError HandlingDevOpsReliabilityx402