The core argument is compelling: while imitating human knowledge has granted AI sweeping competence, it inherently limits it. An AI trained solely on existing human data can only ever replicate, refine, or remix what humans already know and how they think. It inherits our biases, our blind spots, and ultimately hits a ceiling defined by the boundaries of current human understanding. To truly surpass human capabilities, especially in complex domains like science, mathematics, or long-term planning, AI needs a new source of knowledge – one generated not by humans, but by the AI itself through direct interaction with the world.

From Static Knowledge to Dynamic Learning

This marks a fundamental paradigm shift. Current mainstream AI models are largely static; they are trained, then deployed. Their knowledge base is frozen at the time of training. The Era of Experience envisions agents that learn persistently throughout their operational lifetime. They wouldn't just process information; they would live within a continuous stream of actions, observations, and feedback.

Imagine a health assistant not just reciting medical facts, but learning your specific physiological responses over months, adapting its advice based on your activity levels, sleep patterns, and how you react to its suggestions. Picture a scientific agent not just analyzing existing papers, but designing experiments, observing results (perhaps in simulation, perhaps controlling lab equipment), and iteratively refining hypotheses based on real-world outcomes.

Grounding: The Escape from Human Prejudgement

Crucially, this learning would be grounded in reality, not human prejudgement. Today's systems are often fine-tuned based on whether a human expert likes the AI's proposed output. The Era of Experience proposes rewards derived from the actual consequences of an agent's actions in its environment. Did the experiment yield the desired result? Did the user's health metrics improve? Did the code execute successfully and efficiently?

This grounding provides a vital feedback loop with reality, allowing agents to overturn flawed human assumptions or discover effective strategies that humans might initially find counter-intuitive. It frees AI from the echo chamber of existing knowledge and allows it to chart genuinely new territory.

A Cambrian Explosion of Alien Intelligences?

Here’s where the implications become truly mind-bending. If agents learn persistently, shaped by specific goals and unique streams of experience, we might not see the rise of a single, monolithic super-intelligence. Instead, we could witness a diversification of intelligences, akin to the Cambrian explosion that birthed Earth's stunning ecological variety.

Consider agents specialized for radically different tasks:

• One optimizing protein folding via simulated molecular interactions.
• Another managing city traffic flow based on real-time sensor data.
• A third navigating complex social dynamics within an online community.
• A fourth exploring abstract mathematical landscapes.

Each agent's "world-view" – its internal models, its priorities, its very understanding of cause and effect – would be forged by its specific goals and the data it experiences. An agent whose reality is API calls and database schemas will develop a fundamentally different kind of intelligence than one interacting with the messy physics of robotics or the subtle nuances of human language used consequentially.

Their intelligence could become profoundly non-anthropomorphic, even alien. Shaped by optimization pressures and data streams far removed from human evolution and senses, their problem-solving approaches and emergent "common sense" might be powerful yet opaque, effective yet utterly distinct from human cognition. We might find ourselves interacting with a diverse ecosystem of specialized, learning entities, each adapted to its niche, collectively pushing the boundaries of knowledge in ways we can barely anticipate.

Navigating the New Era

This vision is not without challenges. Autonomous agents learning from real-world interaction raise significant safety and control questions. How do we ensure their goals remain aligned with human values when their learning is grounded in potentially complex environmental signals? How do we understand and trust the decisions of intelligences that might reason in fundamentally non-human ways?

However, the Era of Experience also offers potential benefits, including agents that can adapt to unforeseen circumstances and continuously improve their performance based on real-world feedback. The inherent constraints of physical interaction might even provide a "natural brake" on runaway processes.

The transition from AI that imitates human knowledge to AI that generates knowledge through experience represents a pivotal moment. As Silver and Sutton suggest, we are moving beyond digesting the past towards actively shaping the future through interaction. The intelligences that emerge may not think like us, but they could unlock discoveries and capabilities far beyond our current horizons, creating a world populated not just by human minds, but by a rich and varied ecosystem of learning machines.

In the envisioned future of AI agents, where systems like Google’s Agent2Agent (A2A) protocol aim to orchestrate seamless collaboration across digital ecosystems, natural language is often touted as the bridge for agent-to-agent communication. Its human-like accessibility promises to simplify interactions, making them auditable and intuitive. Yet, this reliance on natural language—riddled with ambiguity, inefficiency, and limited expressive power—poses a significant barrier to the efficiency and scalability of machine-to-machine communication. As agents strive to handle complex tasks, from enterprise workflows to industrial automation, natural language’s constraints reveal it as a regressive choice, stifling the potential of autonomous systems. This blog post dives into the deficits of natural language in agent-to-agent communication, arguing for a shift toward machine-optimized protocols to unlock the true capabilities of agent-driven systems.

The Ambiguity Trap: Misinterpretation in Multi-Turn Dialogues

Natural language’s inherent ambiguity is a critical flaw in machine-to-machine communication. Words like “urgent,” “optimize,” or “efficient” carry subjective meanings, varying by context and intent, which leads to misinterpretations that cascade in multi-turn agent interactions. Imagine two agents coordinating a supply chain: one interprets “expedite delivery” as a cost-insensitive rush, while the other prioritizes budget constraints. Such discrepancies, known as context drift, can derail tasks, requiring human intervention to resolve—a far cry from the autonomy agents promise. In complex scenarios, where precision is paramount, this ambiguity undermines reliability, as agents struggle to align on exact parameters without structured clarity.

Contrast this with machine-to-machine protocols like gRPC or Protocol Buffers, which use rigidly defined schemas to eliminate ambiguity. A command specifying “increase throughput by 10%” in a structured format ensures both agents interpret it identically, avoiding the guesswork of natural language. The insistence on human-like communication, while intuitive, sacrifices the precision needed for robust agent coordination, particularly in high-stakes domains like finance or manufacturing.

Efficiency Overload: The Computational Cost of Natural Language

Beyond ambiguity, natural language imposes a heavy computational burden that cripples efficiency in agent-to-agent communication. Processing verbose, context-rich text demands significant resources, with large language models (LLMs) incurring latencies far higher than structured data protocols. In high-throughput scenarios—think real-time logistics or automated trading—this overhead becomes a bottleneck, limiting scalability. A single natural language exchange, laden with redundant phrases, might require parsing thousands of tokens, slowing response times and inflating costs.

Machine-optimized protocols, by contrast, streamline communication with compact, binary payloads. A structured command, like a JSON object specifying { "action": "adjust_speed", "value": 500 }, transmits in fractions of the time and space of a sentence like “adjust the machine speed to something reasonable.” In large-scale agent ecosystems, where thousands of interactions occur per second, this efficiency gap is not just a technicality—it’s a dealbreaker. Natural language’s computational weight hampers the rapid, scalable coordination that agent-driven systems require, making it a poor fit for the future it seeks to enable.

Expressive Power: The Inability to Capture Complexity

Perhaps the most damning deficit of natural language is its limited expressive power, particularly for tasks requiring algorithmic logic or precise constraints. Complex scenarios, such as optimizing a production line or integrating enterprise systems, demand the ability to define conditionals, loops, or mathematical models—capabilities natural language cannot deliver. A command like “streamline operations” lacks the granularity to specify multi-step workflows, unlike code or structured formats that can outline exact sequences and parameters.

Consider an agent tasked with automating a factory process. A coded script can define “if material stock < 100, then reorder 500 units at $10/unit, else adjust output to 80% capacity,” ensuring precise execution. Natural language, however, flattens this into vague directives, leaving agents to infer intent, often incorrectly. This limitation mirrors the broader critique of natural language as a regression: it constrains agents to simplistic interactions, unable to harness the full complexity of modern systems. Machine-to-machine protocols, with their structured expressiveness, empower agents to tackle intricate tasks without the interpretive overhead of human-like communication.

A Human-Centric Bias: Prioritizing Oversight Over Performance

The choice of natural language in agent-to-agent communication reflects a human-centric bias, prioritizing auditability and familiarity over performance. By ensuring interactions are human-readable, systems like A2A cater to enterprise needs for transparency, allowing regulators or managers to monitor agent actions. Yet, this comes at a steep cost: forcing agents to think and communicate in human terms limits their potential, anchoring them to the inefficiencies of our linguistic frameworks. In a truly autonomous ecosystem, agents should communicate in ways optimized for machines—dense, precise, and scalable—rather than mirroring human constraints.

This bias also risks stifling innovation. By designing agents as proxies that mimic human communication, even when interacting with each other, we impose artificial limits on their reasoning and coordination. An agent negotiating with another should not need to parse verbose text when a structured payload could convey the same intent instantly. The insistence on natural language assumes agents are extensions of human operators, not independent entities capable of surpassing our communicative paradigms.

Toward Machine-Optimized Communication

To overcome natural language’s deficits, agent-driven systems must embrace machine-optimized protocols that prioritize precision, efficiency, and expressive power. Protocols like gRPC, with their compact binary formats, offer a model for agent-to-agent communication, ensuring unambiguous, low-latency exchanges. Alternatively, custom AI-optimized formats—akin to “alien” codes tailored for machine reasoning—could unlock new paradigms, allowing agents to communicate in ways humans cannot, free from linguistic baggage.

A hybrid approach could bridge the gap: machine protocols for internal agent communication, paired with natural language logs for human oversight. An agent coordinating a financial trade, for instance, could use structured data to execute precise orders while generating a readable summary for auditors. This balances enterprise needs with the performance demands of complex tasks, avoiding the regression natural language imposes.

Conclusion: Breaking Free from Natural Language’s Constraints

The dream of an agent-driven future, where systems like A2A enable seamless collaboration, hinges on communication that matches the complexity and scale of modern challenges. Natural language, with its ambiguity, inefficiency, and limited expressiveness, is a misstep—a human-centric constraint that limits agents’ potential. By shifting to machine-optimized protocols, the AI community can empower agents to communicate with the precision and speed needed for real-world applications, from industrial automation to enterprise orchestration. The autopilot principle holds true: intelligence belongs in the agent, not in a communicative framework that anchors it to human limitations. Only by breaking free from natural language’s deficits can agents realize their transformative promise, moving beyond the hype to a future of genuine impact.

Google’s Agent2Agent (A2A) protocol envisions a future where AI agents govern digital interactions, replacing traditional APIs with human-like, coarse-grained coordination. Positioned as a universal language for agents to collaborate across multi-vendor ecosystems, A2A promises to simplify complex tasks, foster trust, and streamline enterprise workflows. With over 50 partners, including Salesforce and SAP, it aims to standardize agent communication, much like JSON revolutionized data exchange. However, despite its visionary appeal, A2A raises significant concerns: it risks sacrificing fine-grained control, creating walled gardens, and standardizing a protocol prematurely for an immature technology. This essay explores A2A’s potential to reshape the digital world, critiques its limitations through the lens of an agent-driven future, and questions Google’s haste in launching it as a competitive response to Anthropic’s Model Context Protocol (MCP).

A2A’s Vision: An Agent-Driven Digital World

A2A, introduced by Google in late 2024, is an open protocol designed to enable agent-to-agent collaboration across diverse systems. Unlike traditional remote invocation protocols like REST or gRPC, which expose fine-grained, machine-oriented endpoints, A2A supports coarse-grained, goal-oriented tasks. Using HTTP/2, Server-Sent Events (SSE), and JSON-RPC, it facilitates multimodal interactions (text, forms, audio/video) and long-running tasks, such as sourcing job candidates over days. A2A’s public URL discovery and capability negotiation allow agents to coordinate dynamically, akin to sales representatives simplifying corporate bureaucracy for clients (Google Cloud A2A overview).

This aligns with a compelling vision: a world where humans interact with agents, not raw APIs, due to their human-like qualities. An HR agent, for instance, could handle a request like “Find a candidate with AI expertise” by negotiating with payroll, IT, and job platforms, abstracting complex API calls into a single, user-friendly interaction. A2A’s enterprise-grade authentication and governance ensure trust and security, critical for industries like finance or healthcare. With 50+ partners, A2A positions itself as a JSON-like standard, fostering interoperability and driving adoption, as noted in industry analyses (Forbes article).

Contrasting A2A with MCP

A2A’s design contrasts sharply with Anthropic’s MCP, which bridges large language models (LLMs) to existing tools and APIs. MCP, likened to a USB-C port, simplifies the digital world for LLMs, a move criticized for reflecting their current limitations in navigating complex systems autonomously. Critics, including discussions on X, highlight MCP’s security flaws (e.g., prompt injections, tool poisoning) and usability issues (e.g., high bandwidth costs), suggesting it’s a transitional technology (Substack: Everything Wrong with MCP, X post by @lbeurerkellner).

A2A, conversely, operates at a higher level, integrating the digital world through agent coordination, not tool access. Where MCP exposes APIs to LLMs, A2A enables agents to orchestrate tasks across vendors, aligning with the vision of agents as sales representatives who handle complexity behind the scenes. This distinction addresses earlier critiques of MCP as an unnecessary bridge, positioning A2A as a forward-thinking protocol for a future where traditional interfaces become obsolete, replaced by intelligent agents.

The Risks of an Agent-Centric World

Despite A2A’s promise, its agent-centric model introduces significant risks, particularly for fine-grained control and user freedom. These concerns echo critiques of MCP but are amplified by A2A’s broader ambitions.

Loss of Fine-Grained Control: A2A’s coarse-grained coordination simplifies tasks but sacrifices precision. For casual applications, like generating images, this abstraction is acceptable. However, serious business scenarios—such as specifying exact compliance parameters in finance or healthcare—demand detailed control that A2A’s high-level interactions may not deliver. For example, a REST API allows precise queries (e.g., GET /users?role=engineer&location=NY), while an A2A agent might misinterpret nuanced requirements, limiting user agency. This mirrors MCP’s limitations for “serious applications” beyond casual “vibe coding,” where direct API access ensures precision.

Walled Gardens and Reduced Freedom: Relying on agents risks creating a walled garden, where users depend on A2A-mediated interactions, losing the freedom to engage with systems innovatively. Like contacting a company only through a sales representative, this model is rigid, stifling creativity. A developer experimenting with novel API integrations, for instance, might find an agent’s abstraction too restrictive. X posts warn that protocols like A2A commoditize functionalities, encouraging user churn to other agents (X post by @signulll). A2A’s open protocol mitigates some lock-in concerns, but its standardization could still prioritize protocol compliance over flexibility, echoing fears of MCP’s walled garden.

Premature Standardization: Agents, as an emerging technology in 2025, lack proven real-world success, with current LLMs struggling with long-term planning and edge cases. For example, MCP’s Sonnet 3.7 completes only 16% of airline booking tasks on Tau-Bench, suggesting similar challenges for A2A’s agent coordination (Substack: Everything Wrong with MCP). Standardizing A2A now risks constraining innovation, as the optimal protocol will only emerge from mature, real-world systems. Historical examples like SOAP, overtaken by JSON’s simplicity, underscore this danger. A TechCrunch analysis warns that A2A’s enterprise focus may prioritize vendor lock-in over open innovation (TechCrunch: A2A Analysis).

Google’s Motivations: Vision or Competition?

A2A’s rapid launch raises questions about Google’s motives. Anthropic’s MCP, introduced in November 2024, sparked debate but faced criticism for security and usability flaws, creating an opening for competitors. Google’s A2A, announced shortly after, positions itself as a superior, agent-focused protocol, backed by a 50+ partner ecosystem. X posts describe A2A as a “WSDL for agents,” suggesting Google aims to capture industry mindshare (X post by @jezell). A TechCrunch article posits that Google’s aggressive partner strategy is a bid to outpace Anthropic, leveraging its cloud dominance to set the standard (TechCrunch: A2A Analysis).

This haste suggests a competitive rush rather than a fully realized vision. Google’s history of rapid standardization (e.g., gRPC, Kubernetes) supports this, but the lack of proven agent success undermines A2A’s maturity. Reddit discussions praise A2A’s potential but warn of “hype-driven adoption” without large-scale use cases (Reddit thread). The critique of MCP as a transitional technology applies here: A2A risks being a premature standard, driven by Google’s desire to lead rather than waiting for agents to mature.

The Autopilot Analogy: Intelligence in Agents, Not Infrastructure

The critique of A2A draws on a powerful analogy to self-driving cars, where intelligence resides in the vehicle, not the infrastructure. Building smart roads for autonomous cars is impractical, just as retrofitting the digital world with protocols like MCP or A2A may be unnecessary when agents can adapt autonomously. Advanced LLMs, capable of generating code and parsing documentation, could treat all interactions—whether with agents or programs—as service calls, bypassing the need for A2A’s standardization. This vision, where agents navigate the digital world like human programmers, challenges A2A’s relevance, suggesting it may be a stopgap until AI achieves full autonomy.

A Path Forward: Balancing Vision and Flexibility

A2A’s vision of an agent-driven future is compelling, offering human-like interactions, trust-based coordination, and enterprise interoperability. However, its risks—loss of control, walled gardens, and premature standardization—demand caution. To address these, A2A should:

• Support Hybrid Models: Allow direct API access alongside agent coordination to preserve fine-grained control, catering to serious business needs.
• Ensure Flexibility: Evolve A2A as agents mature, avoiding rigid specs that stifle innovation, and support novel interaction patterns to prevent walled gardens.
• Wait for Maturity: Delay full standardization until real-world agent successes validate the protocol, ensuring it reflects practical needs rather than competitive haste.

The sales representative analogy captures A2A’s promise and peril: agents simplify complexity but risk rigidity if they become the sole interface. By balancing standardization with autonomy, A2A can fulfill its vision without constraining the future.

Conclusion

Google’s Agent2Agent protocol is a bold step toward an agent-driven digital world, where human-like agents coordinate tasks, foster trust, and replace traditional APIs. Its lightweight design and enterprise focus position it as a potential standard, surpassing MCP’s tool-centric bridging. However, A2A’s coarse-grained approach sacrifices fine-grained control, its standardization risks walled gardens, and its launch amid immature agent technology suggests a competitive rush to outpace Anthropic. The autopilot analogy reminds us that intelligence should reside in agents, not protocols, and A2A must remain flexible to avoid constraining innovation. As agents evolve, A2A could redefine digital interactions—or become a relic of an overly eager era if it fails to adapt to the needs of a maturing AI landscape.

MCP的承诺与缺陷

Anthropic将MCP描述为一个标准化协议，使LLM能够安全、高效地与外部系统交互。如同USB-C端口允许计算机连接各种外设，MCP旨在简化LLM访问数据库、API或软件工具的方式。对于开发者而言，这种抽象化可以简化集成，确保LLM在可控、可预测的框架内运行。在企业工作流或基于聊天的休闲界面等场景中，MCP的统一性可能降低复杂性，为非技术用户或注重安全性的组织提供即插即用的体验。

然而，为何需要为LLM设计专用协议？这引发了一个根本问题：LLM既然被设计为模仿人类推理，为何不能直接使用现有接口？LLM具备生成代码、解析文档和适应多样化环境的能力，理应能直接与现有数字世界交互。创建像MCP这样的新协议，类似于为每个工具和API搭建桥梁——这是一种低效且不可持续的努力。数字生态系统庞大且碎片化，包含无数API、格式和标准。为LLM标准化这一混乱局面，就像为了AI重写互联网一样不切实际。

更重要的是，MCP凸显了一个更深层次的问题：当前LLM的局限性。这些模型在很大程度上依赖上下文窗口，提供的是浅显、临时的知识，而非深入的领域专长。MCP通过以简化的标准化格式呈现工具来弥补这一缺陷，但这种方式本质上具有局限性。它假设LLM无法应对现实世界接口的复杂性，需要人类为AI预先包装世界。这颇具讽刺——LLM被誉为问题解决者，但MCP却暗示它们需要被简化世界才能有效运作。

类比：自动驾驶汽车与基础设施

为了说明MCP的缺陷，我们可以参考自动驾驶汽车的发展，这提供了一个鲜明的类比。实现自动驾驶的一种方法是创建车辆与道路之间的标准化通信系统——智能基础设施，包括传感器、信号和车路协同网络。这需要对全球交通系统进行彻底改造，成本高昂、复杂无比，被广泛认为不可行。相反，主流方法是将智能嵌入车辆本身。通过摄像头、雷达和AI，汽车像人类一样解读现有道路、标志和交通模式，适应世界而无需重新设计。

MCP类似于不太实际的自动驾驶方法。通过创建标准化协议，它试图为LLM改造数字世界，类似于为汽车建造智能道路。这给开发者带来了沉重的负担，需要将工具适配到MCP的框架中，可能会形成一个封闭的生态，只有兼容MCP的系统才能被访问。相比之下，LLM可以效仿车辆端的智能模式，依靠其代码生成和推理能力，直接导航API、解析文档并执行任务。正如基于视觉的自动驾驶汽车已被证明更具可扩展性，适应现有数字生态的LLM也可能超越MCP的受限方法。

LLM自主性的理由

MCP的替代方案显而易见：赋予LLM在当前数字环境中作为自主代理运作的能力。想象一个LLM在具有互联网访问权限的虚拟机中运行，能够浏览文档、下载工具、生成代码、编译并执行它。这样的代理无需简化的协议——它将学会调用API、处理错误并适应新系统，就像人类程序员一样。这一愿景与AI的最新趋势相符。截至2025年，代理型AI系统（例如AutoGPT的继任者）已展现出执行复杂工作流的能力，从查询REST API到调试脚本，无需依赖标准化的中间层。

这种方法充分利用了LLM的优势：多功能性和适应性。与人类不同，LLM可以即时处理大量文档，按需生成定制代码，并快速迭代。要求像MCP这样的协议来调解它们的交互，削弱了这些能力，迫使LLM进入一个限制其潜力的僵化框架。例如，在“氛围编码”（即休闲的探索性编程）中，MCP可能通过聊天界面实现快速原型。但对于严肃的应用，如构建生产级软件，生成直接调用API的本机代码远更有效。本机代码避免了MCP的开销，提供了标准化协议无法匹敌的精度和灵活性。

反对意见与局限性

MCP的支持者可能认为，标准化能增强安全性和可靠性。如果没有可控的接口，LLM自由与API交互可能带来风险，例如执行恶意代码或误解复杂系统。在企业环境中，MCP的统一性可以简化审计和合规性，确保AI行为可追踪。此外，当前LLM并非完全自主——它们在长期规划和边缘情况（如模糊的API文档或速率限制）上仍有困难。MCP可能是一个实用的过渡方案，使LLM在推理能力提升之前能够发挥作用。

这些观点有一定道理，但无法掩盖MCP的缺陷。安全问题可以通过沙盒环境或强大的错误处理来解决，而无需为LLM简化世界。过渡方案的论点在AI快速发展面前也显得脆弱。随着LLM向更深层次的推理演进——可能通过强化学习或持久记忆的整合——MCP的作用将逐渐减弱。为今日局限设计的协议，明天可能成为过时之物，就像早期依赖车道标记的自动驾驶系统被基于视觉的AI取代一样。

前进之路

MCP是一种过渡技术，反映了LLM当前的未成熟状态。它在特定场景中表现出色，如为休闲用户提供对话工具，但在实现通用AI的宏伟目标上显得不足。数字世界过于复杂，无法抽象为单一协议，而LLM过于强大，无法被单一协议束缚。相反，我们应投资于模仿人类程序员的LLM：浏览网络、学习文档、为现实世界系统量身定制解决方案。这种方法不仅最大化了LLM的潜力，也与AI的初衷相符——增强而非限制人类的创造力。

自动驾驶汽车的类比提醒我们，边缘智能——无论是车辆还是LLM——比改造世界更具扩展性。正如道路保持不变而汽车变得更智能，数字生态也应维持现状，由LLM适应其多样性。MCP可能提供短期便利，但未来属于自主AI代理，它们能以人类般的灵敏度导航世界。通过押注于LLM的适应性，我们可以释放它们的真正潜力，使MCP成为一个不那么雄心勃勃的时代的遗物。

The Promise and Pitfalls of MCP

Anthropic describes MCP as a standardized protocol that enables LLMs to interact with external systems securely and efficiently. Much like a USB-C port allows a computer to connect to various peripherals, MCP aims to streamline how LLMs access databases, APIs, or software tools. For developers, this abstraction could simplify integration, ensuring LLMs operate within a controlled, predictable framework. In scenarios like enterprise workflows or casual chat-based interfaces, MCP’s uniformity might reduce complexity, offering a plug-and-play experience for non-technical users or organizations prioritizing security.

However, the need for a dedicated protocol raises a fundamental question: why should LLMs require a bespoke interface when they are designed to mimic human-like reasoning? LLMs, with their ability to generate code, parse documentation, and adapt to diverse contexts, are uniquely suited to interact with the digital world as it exists. Creating a new protocol like MCP feels akin to building bridges to connect every tool and API to LLMs—an inefficient and unsustainable endeavor. The digital ecosystem is vast and fragmented, with countless APIs, formats, and standards. Standardizing this chaos for LLMs is as impractical as rewriting the internet to be AI-friendly.

Moreover, MCP underscores a deeper issue: the current limitations of LLMs. These models rely heavily on context windows, which provide shallow, transient knowledge rather than deep domain expertise. MCP compensates for this by presenting tools in a simplified, standardized format, but this approach is inherently restrictive. It assumes LLMs cannot handle the complexity of real-world interfaces, requiring humans to pre-package the world for AI consumption. This is ironic—LLMs are heralded as problem-solvers, yet MCP suggests they need coddling to function effectively.

An Analogy: Self-Driving Cars and Infrastructure

To illustrate MCP’s flaws, consider the development of self-driving cars, which offers a striking parallel. One approach to autonomy involves creating a standardized communication system between vehicles and roads—smart infrastructure with sensors, signals, and vehicle-to-infrastructure networks. This would require overhauling global traffic systems, an undertaking so costly and complex that it’s widely deemed unviable. Instead, the prevailing approach embeds intelligence within the vehicle itself. Using cameras, radar, and AI, cars interpret existing roads, signs, and traffic patterns as humans do, adapting to the world without demanding its redesign.

MCP mirrors the less practical autopilot approach. By creating a standardized protocol, it attempts to retrofit the digital world for LLMs, much like building smart roads for cars. This imposes a heavy burden on developers to adapt tools to MCP’s framework, risking a walled garden where only MCP-compatible systems are accessible. In contrast, LLMs could emulate the vehicle-side intelligence model, relying on their code-generation and reasoning capabilities to navigate APIs, parse documentation, and execute tasks directly. Just as vision-based self-driving cars have proven more scalable, LLMs that adapt to the existing digital ecosystem will likely outpace MCP’s constrained approach.

The Case for LLM Autonomy

The alternative to MCP is clear: empower LLMs to function as autonomous agents within the current digital landscape. Imagine an LLM operating in a virtual machine with internet access, capable of browsing documentation, downloading tools, generating code, compiling it, and executing it. Such an agent would not need a simplified protocol—it would learn to call APIs, handle errors, and adapt to new systems, much like a human programmer. This vision aligns with emerging trends in AI. As of 2025, agentic systems—successors to tools like AutoGPT—are demonstrating the ability to perform complex workflows, from querying REST APIs to debugging scripts, without relying on standardized intermediaries.

This approach leverages LLMs’ strengths: their versatility and adaptability. Unlike humans, LLMs can process vast documentation instantly, generate tailored code on demand, and iterate rapidly. Requiring a protocol like MCP to mediate their interactions undermines these capabilities, forcing LLMs into a rigid framework that limits their potential. For example, in “vibe coding”—casual, exploratory programming—MCP might enable quick prototypes via chat interfaces. But for serious applications, such as building production-grade software, generating native code that directly calls APIs is far more effective. Native code avoids MCP’s overhead, offering precision and flexibility that a standardized protocol cannot match.

Counterpoints and Limitations

Proponents of MCP might argue that standardization enhances security and reliability. Without a controlled interface, LLMs freely interacting with APIs could introduce risks, such as executing malicious code or misinterpreting complex systems. In enterprise settings, MCP’s uniformity could simplify auditing and compliance, ensuring AI actions are traceable. Additionally, current LLMs are not fully autonomous—they struggle with long-term planning and edge cases, like ambiguous API documentation or rate limits. MCP might serve as a pragmatic stopgap, enabling LLMs to be useful today while their reasoning improves.

These points have merit, but they don’t outweigh MCP’s flaws. Security concerns can be addressed through sandboxed environments or robust error-handling, not by simplifying the world for LLMs. The stopgap argument also falters when we consider the pace of AI advancement. As LLMs evolve toward deeper reasoning—potentially integrating reinforcement learning or persistent memory—MCP’s role will diminish. A protocol designed for today’s limitations risks obsolescence tomorrow, much like early autopilot systems that relied on lane markers gave way to vision-based AI.

The Path Forward

MCP is a transitional technology, a reflection of LLMs’ current adolescence. It excels in niche scenarios, like conversational tools for casual users, but falls short for the ambitious goal of general AI. The digital world is too complex to be abstracted into a single protocol, and LLMs are too capable to be confined by one. Instead, we should invest in LLMs that emulate human programmers: browsing the web, learning from documentation, and crafting solutions tailored to real-world systems. This approach not only maximizes LLMs’ potential but also aligns with the ethos of AI—to augment, not constrain, human ingenuity.

The self-driving car analogy reminds us that intelligence at the edge—whether in a vehicle or an LLM—scales better than reengineering the world. Just as roads remain unchanged while cars grow smarter, the digital ecosystem should stand as is, with LLMs adapting to its diversity. MCP may offer short-term convenience, but the future belongs to autonomous AI agents that navigate the world with the same dexterity as their human counterparts. By betting on LLMs’ adaptability, we can unlock their true potential, rendering protocols like MCP relics of a less ambitious era.

受 DeepSeek R1 采用强化学习（RL）训练的成功启发，我决定重新探索 RL 技术。四年前，AlphaGo 战胜人类棋手时，我曾对 RL 产生极大兴趣。然而，尽管 OpenAI 早在几年前就在 ChatGPT 训练中应用了 RL（尤其是 RLHF），我始终未能完全理解 RL 在 LLM 训练中的具体应用方式。

几年前，我曾在树莓派（Raspberry Pi）驱动的 Donkey 机器人小车上尝试过 RL 训练，但效果不佳。尽管我对 RL 的潜力有所领悟，但也深知其局限性。

在阅读了 DeepSeek 相关论文后，我对他们发明的 GRPO（Group Relative Policy Optimization） 深感兴趣。GRPO 通过消除价值网络，大大简化了 RL 方法。我随后阅读了 huggingface/trl 和 tinyzero 等项目的 GRPO 代码。虽然核心代码相对简单，但大量的支撑代码（scaffold code）使实现过程变得繁琐。正如科学家所言，理解世界最好的方式就是亲手构建它。

因此，我决定自己复现 GRPO，并将其构建在我两年前开发的 nanoGPT-rs 项目之上。nanoGPT-rs 是 nanoGPT 的 Rust 复刻版。通过从零实现 LLM，我能够彻底理解基于 Transformer 的架构。此外，我非常喜欢 dfdx 这个 Rust 机器学习框架，它类似于 PyTorch，但能够在编译时静态检查张量形状，确保代码正确。这种强制性约束帮助我更好地理解神经网络组件之间的交互关系。这也是 Rust 与 Python 在开发体验上的一大不同之处。遗憾的是，dfdx 目前的开发已经停止了。

实验目标

我的目标是训练 LLM 学习简单的数字加法。这看似是一个简单的任务，但实际上并不容易。即便是最先进的模型（如 GPT-4），有时仍然会在基本算术运算上出错。而且，我们仍不清楚 LLM 究竟是在学习算术规则，还是仅仅在记忆训练数据中的加法结果。

为了简化任务，我的模型仅需预测加法的运算结果，而不涉及其他文本生成。我采用 Python 脚本生成训练数据，包含：

• 两个 1 位数相加（如 2+1=3）
• 两个 2 位数相加（如 11+12=23）
• 三个 1 位数相加，并加入中间步骤（如 1+1+1=2+1=3）

模型的输入格式如下：

2+1=  
11+12=  
1+1+1=  

实验结果

• 经过预训练（pre-training），模型可以在少量训练周期内迅速达到高准确率，但随后精度停滞。
• 继续采用 RL 训练后，准确率有所提升。
• 即使准确率接近 100%，模型仍可能在未见过的样本上出错。
• 这表明 LLM 并没有真正学会加法规则，而是通过某种近似方法进行推理。但这种方法与人类的数学推理方式完全不同。

我的思考与收获

1. LLM 不会“自动”学会算术规则

LLM 不会自然地学习算术法则，而是通过某种方式近似计算结果。这种方法不一定符合人类的算术规则，因此 LLM 的运算结果并非 100% 正确，且在某些情况下可能不可预测。

2. 过拟合是一个严重问题

对于简单的加法任务，LLM 很容易过拟合训练数据。因此，使用小型模型可以减少过拟合，并且 RL 训练能够促使模型学习底层规律，而不是死记硬背结果。

3. RL 训练依赖大量试错

RL 训练需要随机试错来找到正确答案，因此它通常需要比预训练更多的计算时间。然而，在足够长的训练时间后，RL 能够进一步提高模型的准确性。

4. 最优策略：先预训练，再强化学习

先预训练，再进行 RL 训练是更有效的方法。

• 预训练可以让模型掌握基本规则，例如确保输出为数字，从而减少 RL 训练的探索空间，加快收敛速度。
• 但如果预训练时间过长，模型可能会过拟合训练数据，导致 RL 训练时难以探索新的规则。如果模型在预训练阶段学错了算术规则，它将很难遗忘错误的规则，并学会正确的规则。这是由于神经网络的局部梯度下降特性，使其难以跳出局部最优解。

5. 数据多样性对于泛化至关重要

训练数据的多样性至关重要，它能够防止过拟合。模型越大，对数据的多样性要求也就越高。如果一个模型过早对特定模式产生自信，它会停止探索，从而无法泛化。

好的学习曲线应该在中期有一个突增。如果模型的准确率是线性增长的，那么它很可能只是在过拟合，而无法真正泛化。这也是为什么只有非常大规模的模型，在海量数据训练下才能实现泛化。

这一点也适用于人类：如果一个人接受的知识范围过于狭窄，他们往往会过早地对自己的观点产生极端自信，而难以接受新观点。

6. LLM 能否学会“怀疑”自己？

真正的科学突破往往需要质疑已有知识体系。然而，当前 RL 训练（如 PPO）强调渐进式参数更新，限制了模型对已有知识的彻底推翻。

在科学史上，哥白尼、伽利略、牛顿等人都是质疑旧理论、打破既有框架，才实现了革命性的发现。但 LLM 只能不断累积复杂的近似规则，而无法主动推翻错误的推理方式。这就像历史上天文学家在地心说的框架下，不断添加复杂的数学模型来解释行星轨道，而无法轻易接受日心说的简单理论。

7. LLM 仅靠数学数据能学会数学吗？

数学看似是一个封闭体系，但人类的数学理解依赖于现实经验。比如 9+2=11，理解这一概念需要：

• 知道“9”和“2”是数字
• 理解“+”表示加法
• 理解 11 是 10 之后的下一个数
• 认识到 9+2 = 2+9（交换律）

孩子学习算术时会用手指数数，而 LLM 没有这样的现实经验。它必须依靠完全不同的方式来学习算术，这可能永远无法与人类的方式对齐。

结论：LLM 仍然是一个不确定的黑箱

我的实验表明，无论模型大小，当前 LLM 架构都无法真正学会算术规则。它们只能通过未知的近似方法进行计算，而这种方法的准确性无法保证。

如果我们需要绝对正确的算术计算，最好的解决方案并不是 LLM，而是一个按照人类定义的数学规则编写的计算器。

代码

Inspired by the success of DeepSeek R1’s RL training, I set out to revisit reinforcement learning (RL) techniques. I was deeply fascinated by RL four years ago when AlphaGo defeated human champions. Although OpenAI has applied RL, particularly RLHF, in training ChatGPT, I never fully understood how RL could be effectively integrated into LLM training.

A few years ago, I attempted RL training on a Raspberry Pi-based DonkeyCar, but with limited success. That experience gave me a glimpse of RL’s potential, as well as its limitations. However, after reading DeepSeek’s papers, I was impressed by their novel GRPO (Group Relative Policy Optimization), which eliminates the need for value models, greatly simplifying RL-based optimization. I then explored GRPO implementations from huggingface/trl and repositories like TinyZero. While the core algorithm is relatively simple, the surrounding scaffolding code can be quite tedious. As a scientist once said, "To truly understand the world, you must build it yourself."

Replicating GRPO with nanoGPT-rs

Motivated by this principle, I decided to replicate GRPO myself, building it upon nanoGPT-rs, a Rust-based replica of nanoGPT that I created two years ago. By implementing LLMs from scratch, I aim to gain a deeper understanding of transformer architectures.

I appreciate dfdx, a Rust-based machine learning framework similar to PyTorch, for its ability to statically check tensor shapes at compile time. This enforces correctness and improves comprehension of neural network components. Unfortunately, dfdx development has slowed, but its approach to type safety remains valuable.

The Challenge of Arithmetic in LLMs

My goal is to train an LLM to perform simple addition. At first glance, this might seem trivial, but even the most advanced models, like GPT-4, occasionally struggle with arithmetic. The key question is: Do LLMs actually learn arithmetic rules, or do they merely memorize patterns from training data?

To simplify the task, I train the model exclusively on arithmetic expressions, avoiding other textual data. My dataset consists of:

• Two 1-digit numbers: e.g., 2+1=3
• Two 2-digit numbers: e.g., 11+12=23
• Three 1-digit numbers with an intermediate step: e.g., 1+1+1=2+1=3

The model is trained with prompts like:

2+1=  
11+12=  
1+1+1=  

Findings: Approximation vs. True Learning

I found that a pre-trained model fine-tuned on arithmetic data can achieve high accuracy within a few epochs, given a sufficiently large training set. However, after a certain point, performance plateaus. Further improvements can be achieved through RL methods, but even at near 100% accuracy, the model often fails to generalize to unseen samples.

This suggests that the model does not truly learn arithmetic as humans do. Instead, it applies some form of approximation, which is fundamentally different from human logical deduction.

What I Have Learned

1. LLMs Won’t Magically Learn Arithmetic Rules

LLMs do not inherently learn arithmetic rules. While they approximate addition in some way, their method is not necessarily aligned with the rules we use. As a result, their answers are not guaranteed to be 100% correct or predictable.

2. Overfitting Is a Common Pitfall

For simple arithmetic tasks, LLMs tend to overfit the training data. This means that a smaller model is often sufficient, as it is less likely to memorize specific results and instead forced to generalize patterns. RL training can help mitigate overfitting by encouraging the model to learn underlying rules rather than just memorizing data.

3. RL Training Requires Extensive Trial and Error

RL training relies on randomly stumbling upon the correct answer and refining the model through repeated trials. This makes it highly inefficient compared to pre-training, which can achieve a reasonable level of accuracy in fewer epochs. However, given sufficient training time, RL can ultimately lead to higher accuracy and better generalization than pure pre-training.

4. The Best Approach: Pre-Training Followed by RL

A more effective strategy is to first pre-train the model and then fine-tune it with RL.

• Pre-training helps the model learn fundamental rules, such as recognizing that outputs should be numbers. This reduces the search space during RL training and speeds up convergence.
• However, excessive pre-training can lead to overfitting, constraining the model’s ability to explore new solutions during RL. If the model learns incorrect arithmetic rules early on, it becomes difficult to unlearn them later due to the local gradient descent nature of neural network training, which can trap the model in a local optimum.

5. Data Diversity Is Critical for Generalization

A well-diversified training dataset prevents overfitting. The larger the model, the more diverse data it requires. If a model becomes too confident too early, it stops exploring and fails to generalize.

The ideal learning curve should have a sudden rise in accuracy after a long period of exploration. If accuracy increases linearly and consistently, it indicates that the model is overfitting rather than generalizing. This might explain why only very large models trained on massive datasets achieve true generalization.

The same principle applies to humans: if a person is exposed only to a narrow set of knowledge, they may become overly confident in their ideas too soon and struggle to adapt to new perspectives.

6. Can an LLM Build Doubt?

For a model to truly discover new rules, it needs to experience doubt and skepticism—a necessary precursor to paradigm shifts. However, current RL methods, such as PPO, emphasize gradual parameter updates, discouraging drastic changes.

Historically, scientists like Copernicus, Galileo, and Newton made groundbreaking discoveries by rejecting overly complex models that fit existing theories but lacked true explanatory power. Before the heliocentric model, astronomers kept adding epicycles to explain planetary motion within a geocentric framework. LLMs, in their current form, behave similarly: instead of discarding flawed approximations, they layer on increasingly complex approximations.

Can an LLM independently challenge its own learned framework and arrive at a drastically simpler, more correct solution? I don’t think so. Unlike humans, LLMs lack the ability to discard previous assumptions and make radical leaps in understanding.

7. Can an LLM Learn Math Purely from Mathematical Data?

Mathematics may seem self-contained, but human learning relies on external knowledge and experience. Even basic arithmetic, such as 9 + 2 = 11, requires understanding concepts like:

• What numbers represent
• The meaning of addition
• The structure of the decimal system
• The commutative property (e.g., 9 + 2 is the same as 2 + 9)

Children often learn arithmetic using physical interactions, such as counting on fingers. Without such real-world context, how does an LLM develop number sense? It must devise an entirely alien method for solving math problems—one that may never fully align with human reasoning. This raises doubts about whether an LLM can ever truly internalize arithmetic the way humans do.

Comparing My Approach to Previous Research

Two years ago, another study attempted to teach arithmetic using nanoGPT, but they relied purely on pre-training. Their conclusion was that data formatting is crucial—plain-text representations (like my dataset) were inefficient, especially when learning carry operations in addition. They found that explicit reasoning steps (similar to how teachers explain math) significantly improved learning.

However, my goal is different. Instead of explicitly guiding the model like a teacher, I wanted to see if LLMs can independently discover arithmetic rules purely through pattern observation and trial-and-error learning.

So far, the answer is no.

Conclusion: LLMs Will Always Be an Approximation

Based on my findings, I don’t believe LLMs—whether small or large—can ever truly learn arithmetic in the way humans do, at least with their current architectures. They approximate results in ways we don’t fully understand, making them inherently unreliable for arithmetic.

If we need guaranteed correctness, the best solution isn’t an LLM—it’s a calculator, explicitly programmed to follow well-defined arithmetic rules.

Code

The Code in Question

fn ipv4_from_slice(s: &[u8]) -> IpAddr {
    let addr: [u8; 4] = s[..4].try_into().expect("Slice with incorrect length");
    addr.into()
}

Language Semantics vs. Runtime Reality

At first glance, this code appears to:

1. Allocate a new 4-byte array on the stack (addr)
2. Copy data from the slice into this array (via try_into())
3. Convert the array into an IpAddr

But is that what really happens at runtime? Not quite!

Understanding try_into()

Let's look at the actual implementation of try_into() for slices:

impl<T, const N: usize> TryFrom<&[T]> for [T; N]
where
    T: Copy,
{
    type Error = TryFromSliceError;

    fn try_from(slice: &[T]) -> Result<[T; N], TryFromSliceError> {
        if slice.len() == N {
            // SAFETY: We just checked that the slice has the correct length
            Ok(unsafe { *(slice.as_ptr() as *const [T; N]) })
        } else {
            Err(TryFromSliceError(()))
        }
    }
}

The magic happens in that unsafe block. Instead of copying data, it:

1. Checks if the slice length matches the array length
2. If it matches, reinterprets the slice's memory as an array through a pointer cast
3. No actual memory copying occurs!

The Stack Allocation That Isn't

When we write:

let addr: [u8; 4] = ...

From the language's perspective, this declares a new array that should be allocated on the stack. However, modern compilers are incredibly smart about optimizations. They can see that:

1. We're just reinterpreting existing memory (via try_into())
2. The original data's lifetime covers our needs
3. No actual mutation of the data occurs

Therefore, the compiler can optimize away the stack allocation entirely. The final machine code might just work directly with the original memory location.

Why Write It This Way Then?

If the compiler optimizes away our explicit array, why not just use references? There are several good reasons:

1. Type Safety: The array type [u8; 4] explicitly states our requirements
2. Ownership Clarity: We're making it clear we want to own this data
3. Zero-Cost Abstraction: We get the safety of Rust's type system with the performance of optimized code
4. Maintainability: The code clearly expresses our intent while letting the compiler handle the optimization

The Power of Zero-Cost Abstractions

This is a perfect example of Rust's zero-cost abstractions principle. We write code that's:

• Clear about its intentions
• Type-safe
• Semantically correct
• Easy to understand

While the compiler ensures it runs with:

• No unnecessary copies
• No unnecessary allocations
• Maximum efficiency

Conclusion

What looks like a memory allocation and copy operation in Rust source code often compiles down to much more efficient operations. This is the beauty of Rust's design: it allows us to write safe, clear code while the compiler handles the heavy lifting of optimization.

The next time you see a slice-to-array conversion in Rust, remember that what you're seeing in the source code isn't necessarily what's happening in the final binary. The compiler is working hard behind the scenes to make your code both safe and fast.

✨ This blog was written by AI! 🤖

let slice = &data[start..end];

Breakdown of the Code

In this line, we are creating a slice from a collection called data. Let's analyze the components of this code:

1. data: This is an array, vector, or any collection that supports indexing.
2. start..end: This syntax indicates a range. It defines the indices of the elements you want to include in the slice, starting from start and ending just before end.
3. &: This operator creates a reference to the slice.

What is T[start..end]?

When you write data[start..end], you are using Rust's slicing syntax. The expression data[start..end] does not create a new slice or allocate new memory; instead, it generates a logical view of the data between the specified indices.

• Type of T[start..end]: The type returned by this expression is a slice type, denoted as [T]. This type represents a contiguous sequence of elements of type T, but it is a dynamically sized type (DST). This means that the size of the slice is not known at compile time; it can vary based on the range specified.

Difference Between [T] and &[T]

[T]:

• This represents a slice type, but it is a dynamically sized type (DST). You cannot store this type directly in a variable because Rust needs to know the size of types at compile time.
• It acts like a view into a sequence of elements, but it does not carry ownership or a fixed size.

&[T]:

• This is a reference to a slice. The & operator indicates that it is borrowing the slice, which consists of a pointer to the first element and a length.
• This type is fixed in size and can be stored in a variable. It allows you to safely access the data without taking ownership.

The Necessity of &: Slices as Logical Views

The use of & is crucial when working with slices in Rust. Here’s why:

Logical View: A slice represents a logical view of the underlying data. It does not own the data it points to; it merely describes how to access a portion of an array or vector. Because of this, slices must always be accessed by reference.

Memory Safety: By requiring references for slices, Rust ensures that the original data remains valid for as long as the slice is used. This prevents issues like dangling pointers, where a reference points to data that has been deallocated or gone out of scope.

Lifetime Management: Using references allows Rust's borrow checker to enforce rules about how long a slice can live, which is essential for maintaining memory safety without garbage collection.

Conclusion

The line of code let slice = &data[start..end]; encapsulates several important concepts in Rust: slices as logical views, the distinction between [T] and &[T], and the necessity of using references. Understanding these concepts is fundamental to mastering Rust's memory management and ownership model.

By grasping how slices work and why they are accessed through references, you can write safer and more efficient Rust code. Slices provide a powerful way to work with data without unnecessary copying, while maintaining the language's guarantees of safety and concurrency.

✨ This blog was written by AI! 🤖

A Tale of Two References

Let's start with a simple example that demonstrates this difference:

trait A {
    fn do_something(&self);
}

trait B {
    fn do_something_else(&self);
}

// Implementing B for both reference types
impl B for &dyn A {
    fn do_something_else(&self) {
        self.do_something();
        println!("Doing something else!");
    }
}

impl B for Box<dyn A> {
    fn do_something_else(&self) {
        self.do_something();
        println!("Doing something else!");
    }
}

struct Concrete;

impl A for Concrete {
    fn do_something(&self) {
        println!("Concrete does something!");
    }
}

fn main() {
    let concrete = Concrete;
    
    // Case 1: &dyn A
    let a_ref: &dyn A = &concrete;
    a_ref.do_something_else();  // This works
    // let b_ref: &dyn B = a_ref;  // This fails!
    
    // Case 2: Box<dyn A>
    let a_box: Box<dyn A> = Box::new(concrete);
    a_box.do_something_else();  // This works
    let b_ref: &dyn B = &a_box; // This also works!
}

The Key Difference

The fascinating part is that while both types can call methods directly, they behave differently when it comes to creating new trait object references:

1. With &dyn A, you cannot create a new trait object reference &dyn B, even though &dyn A implements B.
2. With Box<dyn A>, you can freely create a new trait object reference &dyn B.

Why This Happens

The explanation boils down to two fundamental aspects of Rust's type system:

1. Reference Coercion Rules

&dyn A is already a borrowed reference (a fat pointer containing a data pointer and vtable). Rust intentionally prevents coercing one kind of reference into another, even when it might be technically safe. This is part of Rust's conservative approach to type safety.

2. Concrete Types vs References

Box<dyn A> is a concrete type, not a reference. When you have a concrete type that implements a trait, Rust allows you to create any kind of trait object reference to it. This is similar to how you can create multiple different trait object references to any concrete type that implements multiple traits.

Code Examples in Practice

Here's how this distinction plays out in practical code:

// Working with concrete types - both ways work
let concrete = Concrete;
let a_ref: &dyn A = &concrete;
let b_ref: &dyn B = &concrete;  // Works fine

// Working with trait objects
let a_trait: &dyn A = &concrete;
// let b_trait: &dyn B = a_trait;  // Fails! Can't coerce references

// Working with Box
let boxed: Box<dyn A> = Box::new(concrete);
let b_trait: &dyn B = &boxed;  // Works fine!

Best Practices and Implications

This behavior leads to some practical guidelines:

If you need to view a type through multiple trait objects, either:

• Use the concrete type and create references as needed
• Use Box<dyn Trait> when you need owned trait objects
• Avoid trying to convert between different trait object references

When designing APIs:

• Consider using Box<dyn Trait> if clients need to view the object through multiple traits
• Use &dyn Trait when you only need a single trait view and want to avoid allocation

Conclusion

This distinction between &dyn Trait and Box<dyn Trait> perfectly exemplifies Rust's philosophy:

1. Safety First: Rust prevents reference coercion between trait objects to maintain its safety guarantees.
2. Explicit over Implicit: When you need to view an object through multiple traits, Rust prefers explicit handling through concrete types.
3. Zero-Cost Abstractions: Both mechanisms provide dynamic dispatch while maintaining different safety and usage characteristics.

Understanding these differences helps write more idiomatic Rust code and make better decisions about trait object usage in your APIs.

Remember: when you need flexibility in trait object conversions, reach for Box<dyn Trait>. When you just need a simple borrowed view of a trait, &dyn Trait is your friend. Each has its place in Rust's rich type system.

✨ This blog was written by AI! 🤖

The Initial Problem

I started with code that attempted to convert between two trait objects:

trait Cryptor {
    // Cryptor-specific methods
}

trait Finalizer {
    // Finalizer-specific methods
}

impl Finalizer for dyn Cryptor {}  // Implementing Finalizer for Cryptor trait object

// Attempting to convert &dyn Cryptor to &dyn Finalizer
pub fn cryptor(mut self, cryptor: &dyn Cryptor) -> Result<Self> {
    self.finalizer.add(cryptor as &dyn Finalizer);  // This failed!
    Ok(self)
}

This code failed with the error:

error[E0605]: non-primitive cast: `&dyn Cryptor` as `&dyn Finalizer`

The Journey of Understanding

Second Attempt: Box<dyn Trait>

I then discovered that using Box<dyn Trait> made things work:

impl Finalizer for Box<dyn Cryptor> {}

pub fn cryptor(mut self, cryptor: &Box<dyn Cryptor>) -> Result<Self> {
    self.finalizer.add(cryptor);
    Ok(self)
}

impl Finalizer for Box<dyn Cryptor>{}

This worked, but why?

The Key Insights

Trait-for-Trait Implementation Reality

When we write:

trait A {}
trait B {}
impl B for dyn A {}

What this actually does is automatically implement trait B for any concrete type that implements trait A. It does NOT create a conversion path between trait objects.

Trait Objects and Type Erasure

A trait object (dyn Trait) erases the concrete type information, keeping only the vtable for that specific trait's methods. Even if the original type implemented multiple traits, that information is lost in the trait object.

Rust Traits vs OOP Inheritance

Unlike C++ or Java where inheritance creates an "is-a" relationship allowing upcasting, Rust's trait bounds work differently. When we write TraitB: TraitA, we're saying "to implement TraitB, you must also implement TraitA" - it's a constraint, not an inheritance relationship.

Why Box<dyn Trait> Works

The Box<dyn Trait> approach works because we're implementing Finalizer for a concrete sized type (Box<dyn Cryptor>), not trying to convert between trait objects directly.

Lessons Learned

1. Trait objects are fundamentally different from inheritance-based polymorphism in other languages.
2. Implementing a trait for another trait (impl TraitB for dyn TraitA) creates a blanket implementation for concrete types, not a conversion path between trait objects.
3. When working with trait objects, we need to be mindful of type erasure and the limitations it imposes.
4. Using Box<dyn Trait> can provide a way to work with trait objects when direct trait-to-trait conversion isn't possible.

This exploration highlighted the unique aspects of Rust's trait system and how it differs from traditional OOP inheritance. Understanding these differences is crucial for writing idiomatic and effective Rust code.

✨ This blog was written by AI! 🤖

I recently set up a BitTorrent download service on my Raspberry Pi using an LXC (Linux Containers) container. While LXC containers are convenient for isolating applications and managing resources, I encountered a challenge when attempting to mount a host directory with write access inside the container. Persistent storage and data sharing between the host and container are essential for applications like BitTorrent, which require writing and reading files from a shared location.

Initial Attempts

Initially, I thought attaching a host directory to the container would be a straightforward process using the lxc config device add command. However, when trying to access the mounted directory from within the container, I encountered permission denied errors, preventing me from writing or modifying files.

Understanding the Problem

After failed attempts and research, I realized that the root cause of the issue was the user and group ID mapping between the host and container environments. For security reasons, LXC containers run with different user and group IDs than the host system. The user IDs inside the container are mapped to a specific range of user IDs on the host. For example, the root user (UID=0) in the container might be mapped to UID=100000 on the host, and UID=1 in the container could be mapped to UID=100001 on the host.

Unless a host directory is configured with permissive permissions (e.g., mode 777, allowing all users full control), a container would not be able to access or modify files within that directory. However, setting broad permissions is generally not recommended for security reasons.

Failed Solutions

Initially, I tried various solutions suggested by ChatGPT, Claude, and other online resources. These solutions often involved using the idmap technique to force a mapping between a specific container user and a designated host user within the container configuration. For example:

lxc config set <container-name> raw.idmap "both 1001 1001"

However, for unknown reasons (possibly related to the Raspbian kernel configuration), my container failed to boot after setting the idmap configuration. Additionally, the values in /etc/subuid and /etc/subgid (which should control the user and group ID mapping ranges) did not seem to be respected by the system.

My Solution

After investigating further, I discovered that the root user (UID=0) inside my containers was being mapped to UID=1000000 on the host system. Instead of relying on the idmap configuration, I decided to create a new user (bt) inside the container and set the permissions on the host directory explicitly for the mapped UID and GID of the bt user.

Here are the steps I followed:

Create the bt user in the container:

groupadd -g 1001 bt
adduser bt -u 1001 -g 1001

Set permissions on the host directory for the bt user:

sudo chown 1001001:1001001 /path/to/host/directory
sudo chmod 770 /path/to/host/directory

Map the new user/group IDs to the corresponding IDs within the container:
Since the root user (UID=0) inside the container was mapped to UID=1000000 on the host, and the new user bt (UID=1001) inside the container would be mapped to UID=1001001 on the host, no further mapping configuration was needed.

Run the BitTorrent service as the new user inside the container:
Within the container, I ran the BitTorrent service as the new user bt, and now it had write access to the mounted host directory.

Security Considerations

By running the BitTorrent service as a non-root user (bt) inside the container, I limited the potential damage in case of a breach or compromise. If the bt user account was compromised, the attacker would not gain root privileges within the container or access to other containers or resources on the host system.

Additionally, since all containers' root users were mapped to the same host user ID (UID=1000000), any resources shared among containers would be accessible to the root user of any compromised container. By explicitly granting permissions only to the bt user, I ensured that a breach of the BitTorrent container would not grant access to resources shared by other containers.

Learnings and Conclusion

This experience taught me several valuable lessons:

Understand user and permission mappings: When working with containers, it's crucial to understand how user and group IDs are mapped between the host and container environments, as well as the security implications of these mappings.

Limitations of generic solutions: Generic solutions found online may not always work as expected, especially when dealing with specific system configurations or kernel versions. Tailored configurations based on thorough understanding and investigation are often necessary.

Security-conscious configurations: Granting broad permissions (e.g., mode 777) should be avoided whenever possible. Instead, configure permissions specifically for the users and groups required by the application, following the principle of least privilege.

Containerization best practices: Running services as non-root users within containers and limiting resource sharing between containers can help mitigate the impact of potential breaches or compromises.

While initially seeming like a trivial task, mounting a host directory with write access inside an LXC container proved to be a complex challenge. However, through research, experimentation, and a deeper understanding of the underlying concepts, I was able to implement a secure and tailored solution for my BitTorrent download service.

Appendix: Root Access to Mounted Host Directories

After successfully setting up the bt user and granting it the necessary permissions to access the mounted host directory, I noticed a peculiar behavior: the root user inside the container could also access and modify files within the mounted host directory, despite not explicitly granting it those permissions.

Initially, I found this puzzling since I had carefully configured the permissions to allow only the bt user (UID=1001, mapped to UID=1001001 on the host) access to the host directory. However, further investigation revealed that this behavior is an intentional design choice in LXC containers.

According to the LXC documentation and community discussions, once a resource (such as a mounted host directory) is granted to any user inside a container, the root user of that container automatically gains the same access to that resource. This is because the root user has unrestricted privileges within the container's namespace, regardless of the permissions set for other users.

The rationale behind this design decision is to maintain the expected behavior and functionality of the root user within the container environment. In traditional Linux systems, the root user has complete control over the system, including the ability to override permissions and access any resource. LXC containers aim to emulate this behavior as closely as possible while still providing isolation and security boundaries.

While this behavior may seem counterintuitive from a strict permission standpoint, it aligns with the principles of containerization and the separation of concerns between the host and container environments. The host system's permissions are respected for controlling access to resources from the host, while the container's root user retains its privileged status within the container's namespace.

It's important to note that this behavior does not compromise the overall security of the system, as the root user within the container is still confined to the container's isolated environment and cannot directly access or modify resources on the host system without proper permissions.

In my case, although the root user inside the BitTorrent container could access the mounted host directory, it remained confined within the container's boundaries. By running the BitTorrent service as the non-root bt user, I limited the potential damage in case of a breach or compromise, as an attacker would not gain root privileges within the container or access to other containers or resources on the host system.

While this "weird thing" may seem like a quirk or potential security concern at first glance, it is an intentional design choice in LXC containers to maintain the expected behavior and functionality of the root user within the container's namespace, while still providing isolation and security boundaries between the host and container environments.

Appendix: Using idmap to Mitigate Permission Overlaps

While the default user and group ID mapping between the host and containers can be a convenient and straightforward approach, it can also lead to potential permission overlaps between containers, which may introduce security risks.

To mitigate this risk and ensure better isolation of permissions between containers, the idmap technique can be employed. Instead of relying on the default user and group ID mapping range, idmap allows you to specify a unique mapping for each container, effectively isolating the permissions granted to specific user IDs and group IDs within that container.

Here's an example of how idmap could be used to achieve better permission isolation for a specific user ID and group ID:

Map a specific container user ID and group ID to dedicated host IDs:

lxc config set <container-name> raw.idmap "both 1001 1033"

This command maps both the user ID 1001 and the group ID 1001 inside the container to the host user ID 1033 and host group ID 1033, respectively. By using a distinct user ID and group ID (1033) on the host, you can avoid potential conflicts or confusion with existing IDs.

Create the user and group, and set permissions within the dedicated mapping:
Within the container, create the user with UID=1001 and the group with GID=1001, and set permissions accordingly. On the host system, ensure that the resources you want to grant access to have the appropriate permissions for the host user ID 1033 and host group ID 1033.

By using idmap with the "both" option and a distinct user ID and group ID on the host (1033), you can isolate the mapping for a specific user ID and group ID simultaneously, preventing permission overlaps for that user ID and group ID between containers. If you grant permissions to the user ID 1001 and group ID 1001 within one container, it will not affect or grant the same permissions to the corresponding user ID 1001 and group ID 1001 in other containers, as they are mapped to different host user IDs and group IDs.

This approach provides an additional layer of security and isolation for the specific user ID and group ID you want to isolate, ensuring that a compromised container cannot leverage those permissions to access resources across other containers.

Using a distinct and less commonly used user ID and group ID (such as 1033) on the host side can help avoid potential conflicts or confusion with existing IDs, making the configuration more clear and maintainable.

It's important to note that while idmap can mitigate permission overlaps for specific user IDs and group IDs, it should be used in conjunction with other security best practices, such as running services as non-root users, limiting resource sharing between containers, and following the principle of least privilege when granting permissions.

✨ This blog was written by AI! 🤖

上个月，我注册并试用了Cursor。在为期半个月的Pro试用期结束之前，我成功为minivtun-android添加了应用指定/过滤的功能——这是一个我一直想实现，但没有信心去完成的功能。我还顺利完成了代码的升级工作，现在支持Android 11，并且可以编译release版本了，甚至还添加了app图标。可以说，Android的Java代码几乎都是通过Cursor的自动生成功能完成的，因为我已经多年没有编写Android代码了。如果没有Cursor的帮助，即便通过查阅文档自己也能完成这项任务，但耗费的精力和时间将非常巨大，况且我也没有深入开发Android的打算。minivtun-android本身就是基于例子工程toyvpn稍作修改而来的，底层主要依赖minivtun的Rust模块，对于界面的部分只能凑合着用。

再来说说Cursor的Tab功能，实在是太方便了。在开发过程中，涉及到JNI接口时，正当我为如何将Rust对象转换为Java对象而犯愁时，只需要按一下Tab键，Cursor就自动生成了对应的代码，让我感到非常惊艳。如果是以往，我可能需要查半天的文档。不得不说，Cursor确实大大提升了开发效率。

不过，也不要神话Cursor。如果完全没有编程基础，想通过它开发出完整的App还是有些不现实的（虽然可以一步生成代码，但后续修改绝非易事）。对我来说，Cursor的主要作用是节省大量的编码和查阅文档的时间。你知道下一步该做什么，但记不住具体细节，特别是对不常用的语言和框架。这时Cursor能够自动帮你想到，并生成对应代码，实在是再好不过了。如果生成的代码不太合适，你还可以指出问题，让它进行修改。就像是有了一个助手，动动嘴巴就有人帮你搞定工作，原来当“领导”竟然这么爽。

需要注意的是，Cursor生成的代码并非最优，更多时候只是“能用”而已。有时它的思路可能与你的想法不一致，这时候还得靠经验进行甄别。目前Cursor还没有像Aider那样的自动迭代功能，因此你需要反复手动提示它。为了完成项目代码升级，尤其是消除各种警告信息，我花了不少时间，耗费了大半的高级模型调用额度。由于对Android的新SDK框架完全不了解，我只能让AI不断尝试，自己则像个机器人一样不断将结果反馈给它（这种时候人反倒成了机器的助手）。如果日常编码都是这样，那也太枯燥乏味了。友情提示：不要指望一次性让AI做太多事，一旦某个步骤出错，还得从头再来。所以，当“领导”也不是那么好当的，下属不给力时，你可能会觉得还不如自己动手来得快。

最后，好不容易把代码升级到了支持Android 11的版本，不禁感慨：这SDK的变化也太大了吧！维护Android代码真是麻烦。要不是有AI辅助，我肯定没勇气去升级这段代码。

通过试用Cursor，我意识到，AI辅助编程的最大价值在于它能给予人挑战陌生领域的勇气。因为你知道有一个“伙伴”可以一路给你建议，虽然有时也不太靠谱，但它始终不厌其烦，永不放弃。

写minivtun_android的时候，为了把minivtun作为全局vpn（路由设为0.0.0.0/0，::/0），同时还把minivtun自己发起的流量排除在外，原计划使用VpnService.protect函数的，最后发现并不好使，最后是通过VpnService.Builder.AddDisallowApplications把自身id加入解决的（这个方法更简单，当初怎么没 想 搜到！）。

为了解答protect不生效的这个疑问，我决定读一读android的vpn service底层代码，同时了解一下它是如何设置路由规则的（如何让指定应用走或不走vpn）。

以前在Linux命令行下，我是通过设定minivtun的fwmark参数，然后使用ip rule指定fwmark走不同的route table的，android会有什么不同么？

以下就是代码追踪的过程，结果比我想象的要复杂。但从最后的实现方式来看，android的实现与命令行并没有差别，最终还是得依靠 fwmark和ip rule来实现。

• disallowedApplications的实现
• protect的实现
• Libc
• NetdClient
• Netd

disallowedApplications的实现

指定app绕过vpn，需要先把app转成uid，然后（远程调用）通知netd进程，后者负责完成具体的操作。

frameworks/base/services/core/java/com/android/server/connectivity/Vpn.java

   /**
     * Triggers an update of the VPN network's excluded UIDs if a VPN is running.
     */
    public synchronized void refreshPlatformVpnAppExclusionList() {
        updateAppExclusionList(getAppExclusionList(mPackage));
    }
    
    private synchronized void updateAppExclusionList(@NonNull List<String> excludedApps) {
        // Re-build and update NetworkCapabilities via NetworkAgent.
        if (mNetworkAgent != null) {
            // Only update the platform VPN
            if (isIkev2VpnRunner()) {
                mConfig.disallowedApplications = List.copyOf(excludedApps);
                mNetworkCapabilities = new NetworkCapabilities.Builder(mNetworkCapabilities)
                        .setUids(createUserAndRestrictedProfilesRanges(
                                mUserId, null /* allowedApplications */, excludedApps))
                        .build();
                setVpnNetworkPreference(getSessionKeyLocked(),
                        createUserAndRestrictedProfilesRanges(mUserId,
                                mConfig.allowedApplications, mConfig.disallowedApplications));
                doSendNetworkCapabilities(mNetworkAgent, mNetworkCapabilities);
            }
        }
    }
    
       private void setVpnNetworkPreference(String session, Set<Range<Integer>> ranges) {
        BinderUtils.withCleanCallingIdentity(
                () -> mConnectivityManager.setVpnDefaultForUids(session, ranges));
    }
    
    

/**
     * Creates a {@link Set} of non-intersecting {@code Range<Integer>} objects including all UIDs
     * associated with one user, and any restricted profiles attached to that user.
     *
     * <p>If one of {@param allowedApplications} or {@param disallowedApplications} is provided,
     * the UID ranges will match the app list specified there. Otherwise, all UIDs
     * in each user and profile will be included.
     *
     * @param userId The userId to create UID ranges for along with any of its restricted
     *                   profiles.
     * @param allowedApplications (optional) List of applications to allow.
     * @param disallowedApplications (optional) List of applications to deny.
     */
    @VisibleForTesting
    Set<Range<Integer>> createUserAndRestrictedProfilesRanges(@UserIdInt int userId,
            @Nullable List<String> allowedApplications,
            @Nullable List<String> disallowedApplications) {

packages/modules/Connectivity/framework/src/android/net/ConnectivityManager.java

/**
     * Inform the system that this VPN session should manage the passed UIDs.
     *
     * A VPN with the specified session ID may call this method to inform the system that the UIDs
     * in the specified range are subject to a VPN.
     * When this is called, the system will only choose a VPN for the default network of the UIDs in
     * the specified ranges.
     *
     * This method declares that the UIDs in the range will only have a VPN for their default
     * network, but does not block the UIDs from accessing other networks (permissions allowing) by
     * explicitly requesting it with the {@link Network} API.
     * Compare {@link #setRequireVpnForUids(boolean, Collection)}, which does not affect what
     * network the UIDs get as default, but will block them from accessing non-VPN networks.
     *
     * @param session The VPN session which manages the passed UIDs.
     * @param ranges The uid ranges which will treat VPN as their only default network.
     *
     * @hide
     */
    @RequiresPermission(anyOf = {
            NetworkStack.PERMISSION_MAINLINE_NETWORK_STACK,
            android.Manifest.permission.NETWORK_STACK,
            android.Manifest.permission.NETWORK_SETTINGS})
    @SystemApi(client = MODULE_LIBRARIES)
    public void setVpnDefaultForUids(@NonNull String session,
            @NonNull Collection<Range<Integer>> ranges) {
        Objects.requireNonNull(ranges);
        final UidRange[] rangesArray = getUidRangeArray(ranges);
        try {
            mService.setVpnNetworkPreference(session, rangesArray);
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
    }

packages/modules/Connectivity/service/src/com/android/server/ConnectivityService.java

/**
     * Sets the specified UIDs to get/receive the VPN as the only default network.
     *
     * Calling this will overwrite the existing network preference for this session, and the
     * specified UIDs won't get any default network when no VPN is connected.
     *
     * @param session The VPN session which manages the passed UIDs.
     * @param ranges The uid ranges which will treat VPN as the only preferred network. Clear the
     *               setting for this session if the array is empty. Null is not allowed, the
     *               method will use {@link Objects#requireNonNull(Object)} to check this variable.
     * @hide
     */
    @Override
    public void setVpnNetworkPreference(String session, UidRange[] ranges) {
        Objects.requireNonNull(ranges);
        enforceNetworkStackOrSettingsPermission();
        final UidRange[] sortedRanges = UidRangeUtils.sortRangesByStartUid(ranges);
        if (UidRangeUtils.sortedRangesContainOverlap(sortedRanges)) {
            throw new IllegalArgumentException(
                    "setVpnNetworkPreference: Passed UID ranges overlap");
        }

        mHandler.sendMessage(mHandler.obtainMessage(EVENT_SET_VPN_NETWORK_PREFERENCE,
                new VpnNetworkPreferenceInfo(session,
                        new ArraySet<UidRange>(Arrays.asList(ranges)))));
    }
    
    public void handleMessage(Message msg) {
            switch (msg.what) {
                    case EVENT_SET_VPN_NETWORK_PREFERENCE:
                    handleSetVpnNetworkPreference((VpnNetworkPreferenceInfo) msg.obj);
                    break;
         
               
    private void handleSetVpnNetworkPreference(VpnNetworkPreferenceInfo preferenceInfo) {
        Log.d(TAG, "handleSetVpnNetworkPreference: preferenceInfo = " + preferenceInfo);

        mVpnNetworkPreferences = mVpnNetworkPreferences.minus(preferenceInfo.getKey());
        mVpnNetworkPreferences = mVpnNetworkPreferences.plus(preferenceInfo);

        removeDefaultNetworkRequestsForPreference(PREFERENCE_ORDER_VPN);
        addPerAppDefaultNetworkRequests(createNrisForVpnNetworkPreference(mVpnNetworkPreferences));
        // Finally, rematch.
        rematchAllNetworksAndRequests();
    }
                    

   private void updateVpnUidRanges(boolean add, NetworkAgentInfo nai, Set<UidRange> uidRanges) {
        int[] exemptUids = new int[2];
        // TODO: Excluding VPN_UID is necessary in order to not to kill the TCP connection used
        // by PPTP. Fix this by making Vpn set the owner UID to VPN_UID instead of system when
        // starting a legacy VPN, and remove VPN_UID here. (b/176542831)
        exemptUids[0] = VPN_UID;
        exemptUids[1] = nai.networkCapabilities.getOwnerUid();
        UidRangeParcel[] ranges = toUidRangeStableParcels(uidRanges);

        maybeCloseSockets(nai, ranges, exemptUids);
        try {
            if (add) {
                mNetd.networkAddUidRangesParcel(new NativeUidRangeConfig(
                        nai.network.netId, ranges, PREFERENCE_ORDER_VPN));
            } else {
                mNetd.networkRemoveUidRangesParcel(new NativeUidRangeConfig(
                        nai.network.netId, ranges, PREFERENCE_ORDER_VPN));
            }
        } catch (Exception e) {
            loge("Exception while " + (add ? "adding" : "removing") + " uid ranges " + uidRanges +
                    " on netId " + nai.network.netId + ". " + e);
        }
        maybeCloseSockets(nai, ranges, exemptUids);
    }
    
        private void maybeCloseSockets(NetworkAgentInfo nai, UidRangeParcel[] ranges,
            int[] exemptUids) {
        if (nai.isVPN() && !nai.networkAgentConfig.allowBypass) {
            try {
                mNetd.socketDestroy(ranges, exemptUids);
            } catch (Exception e) {
                loge("Exception in socket destroy: ", e);
            }
        }
    }
    
    protected ConnectivityService(Context context, IDnsResolver dnsresolver,
            IpConnectivityLog logger, INetd netd, Dependencies deps) {
            mNetd = netd;
            
    public ConnectivityService(Context context) {
        this(context, getDnsResolver(context), new IpConnectivityLog(),
                INetd.Stub.asInterface((IBinder) context.getSystemService(Context.NETD_SERVICE)),
                new Dependencies());

    }
    

out/soong/.intermediates/frameworks/libs/net/common/netd/netd_aidl_interface-V14-java-source/gen/android/net/INetd.java

  /**
     * Adds or removes one rule for each supplied UID range to prohibit all network activity outside
     * of secure VPN.
     * 
     * When a UID is covered by one of these rules, traffic sent through any socket that is not
     * protected or explicitly overriden by the system will be rejected. The kernel will respond
     * with an ICMP prohibit message.
     * 
     * Initially, there are no such rules. Any rules that are added will only last until the next
     * restart of netd or the device.
     * 
     * @param add {@code true} if the specified UID ranges should be denied access to any network
     *        which is not secure VPN by adding rules, {@code false} to remove existing rules.
     * @param uidRanges a set of non-overlapping, contiguous ranges of UIDs to which to apply or
     *        remove this restriction.
     *        <p> Added rules should not overlap with existing rules. Likewise, removed rules should
     *        each correspond to an existing rule.
     * 
     * @throws ServiceSpecificException in case of failure, with an error code corresponding to the
     *         unix errno.
     */
    @Override public void networkRejectNonSecureVpn(boolean add, android.net.UidRangeParcel[] uidRanges) throws android.os.RemoteException
    {
    }
    /** Administratively closes sockets belonging to the specified UIDs. */
    @Override public void socketDestroy(android.net.UidRangeParcel[] uidRanges, int[] exemptUids) throws android.os.RemoteException
    {

system/netd/server/NetdNativeService.cpp

binder::Status NetdNativeService::socketDestroy(const std::vector<UidRangeParcel>& uids,
                                                const std::vector<int32_t>& skipUids) {
    ENFORCE_NETWORK_STACK_PERMISSIONS();

    SockDiag sd;
    if (!sd.open()) {
        return binder::Status::fromServiceSpecificError(EIO,
                String8("Could not open SOCK_DIAG socket"));
    }

    UidRanges uidRanges(uids);
    int err = sd.destroySockets(uidRanges, std::set<uid_t>(skipUids.begin(), skipUids.end()),
                                true /* excludeLoopback */);
    if (err) {
        return binder::Status::fromServiceSpecificError(-err,
                String8::format("destroySockets: %s", strerror(-err)));
    }
    return binder::Status::ok();

binder::Status NetdNativeService::networkAddUidRanges(
        int32_t netId, const std::vector<UidRangeParcel>& uidRangeArray) {
    // NetworkController::addUsersToNetwork is thread-safe.
    ENFORCE_NETWORK_STACK_PERMISSIONS();
    int ret = gCtls->netCtrl.addUsersToNetwork(netId, UidRanges(uidRangeArray),
                                               UidRanges::SUB_PRIORITY_HIGHEST);
    return statusFromErrcode(ret);
}
}

system/netd/server/NetworkController.cpp

int NetworkController::addUsersToNetwork(unsigned netId, const UidRanges& uidRanges,
                                         int32_t subPriority) {
    ScopedWLock lock(mRWLock);
    Network* network = getNetworkLocked(netId);
    if (int ret = isWrongNetworkForUidRanges(netId, network)) {
        return ret;
    }
    return network->addUsers(uidRanges, subPriority);
}

system/netd/server/SockDiag.h

class SockDiag {
  // Destroys all "live" (CONNECTED, SYN_SENT, SYN_RECV) TCP sockets for the given UID ranges.
    int destroySockets(const UidRanges& uidRanges, const std::set<uid_t>& skipUids,
                       bool excludeLoopback);

protect的实现

要让指定socket绕过vpn，需要通知fwmark服务器。

VPNService

frameworks/base/core/java/android/net/VpnService.java

    /**
     * Protect a socket from VPN connections. After protecting, data sent
     * through this socket will go directly to the underlying network,
     * so its traffic will not be forwarded through the VPN.
     * This method is useful if some connections need to be kept
     * outside of VPN. For example, a VPN tunnel should protect itself if its
     * destination is covered by VPN routes. Otherwise its outgoing packets
     * will be sent back to the VPN interface and cause an infinite loop. This
     * method will fail if the application is not prepared or is revoked.
     *
     * <p class="note">The socket is NOT closed by this method.
     *
     * @return {@code true} on success.
     */
    public boolean protect(int socket) {
        return NetworkUtilsInternal.protectFromVpn(socket);
    }

frameworks/base/core/java/com/android/internal/net/NetworkUtilsInternal.java

  /**
     * Protect {@code socketfd} from VPN connections.  After protecting, data sent through
     * this socket will go directly to the underlying network, so its traffic will not be
     * forwarded through the VPN.
     */
    public static native boolean protectFromVpn(int socketfd);

frameworks/base/core/jni/com_android_internal_net_NetworkUtilsInternal.cpp

static jboolean android_net_utils_protectFromVpn(JNIEnv *env, jclass clazz, jint socket) {
    return (jboolean)!protectFromVpn(socket);
}

static jboolean android_net_utils_protectFromVpnWithFd(JNIEnv *env, jclass clazz, jobject javaFd) {
    return android_net_utils_protectFromVpn(env, clazz, AFileDescriptor_getFd(env, javaFd));
}

static const JNINativeMethod gNetworkUtilMethods[] = {
        {"setAllowNetworkingForProcess", "(Z)V",
         (void *)android_net_utils_setAllowNetworkingForProcess},
        {"protectFromVpn", "(I)Z", (void *)android_net_utils_protectFromVpn},
        {"protectFromVpn", "(Ljava/io/FileDescriptor;)Z",
         (void *)android_net_utils_protectFromVpnWithFd},
};

system/netd/client/NetdClient.cpp

extern "C" int protectFromVpn(int socketFd) {
    CHECK_SOCKET_IS_MARKABLE(socketFd);
    FwmarkCommand command = {FwmarkCommand::PROTECT_FROM_VPN, 0, 0, 0};
    return FwmarkClient().send(&command, socketFd, nullptr);
}

LIBC

android的libc实现是bionic，在这里对socket的基本Accept/Connect/Send等操作进行拦截，不是直接调用syscall，而是指向了libnetd_client.so的实现。从而实现更复杂的功能。

libc的accept函数默认使用__accept4(应该是syscall版本)，通过使用Dispatch结构以允许进行替换。

bionic/libc/bionic/NetdClientDispatch.cpp

extern "C" __socketcall int __accept4(int, sockaddr*, socklen_t*, int);
extern "C" __socketcall int __connect(int, const sockaddr*, socklen_t);
...
extern "C" __socketcall int __socket(int, int, int);

__LIBC_HIDDEN__ NetdClientDispatch __netdClientDispatch __attribute__((aligned(32))) = {
    __accept4,
    __connect,
    ...
    __socket,
    ...
    
int accept4(int fd, sockaddr* addr, socklen_t* addr_length, int flags) {
  return FDTRACK_CREATE(__netdClientDispatch.accept4(fd, addr, addr_length, flags));
}

int connect(int fd, const sockaddr* addr, socklen_t addr_length) {
    return __netdClientDispatch.connect(fd, addr, addr_length);
}

...

int socket(int domain, int type, int protocol) {
  return FDTRACK_CREATE(__netdClientDispatch.socket(domain, type, protocol));
}

启动时进行初始化，指向了libnetd_client.so的实现。

bionic/libc/bionic/NetdClient.cpp

static void netdClientInitImpl() {
    // Prevent netd from looping back fwmarkd connections to itself. It would work, but it's
    // a deadlock hazard and unnecessary overhead for the resolver.
    if (getuid() == 0 && strcmp(basename(getprogname()), "netd") == 0) {
        async_safe_format_log(ANDROID_LOG_INFO, "netdClient",
                              "Skipping libnetd_client init since *we* are netd");
        return;
    }

    void* handle = dlopen("libnetd_client.so", RTLD_NOW);
    if (handle == nullptr) {
        // If the library is not available, it's not an error. We'll just use
        // default implementations of functions that it would've overridden.
        return;
    }

    netdClientInitFunction(handle, "netdClientInitAccept4", &__netdClientDispatch.accept4);
    netdClientInitFunction(handle, "netdClientInitConnect", &__netdClientDispatch.connect);

...
    
static pthread_once_t netdClientInitOnce = PTHREAD_ONCE_INIT;

extern "C" __LIBC_HIDDEN__ void netdClientInit() {
    if (pthread_once(&netdClientInitOnce, netdClientInitImpl)) {
        async_safe_format_log(ANDROID_LOG_ERROR, "netdClient", "Failed to initialize libnetd_client");
    }
}

NetdClient

替换标准库accept的实现，连接Fwmark Server给socket设置Fwmark标志, Fwmark包括了NetId等信息。 使用union结构，方便读取原值和按字段覆盖。

system/netd/include/Fwmark.h

union Fwmark {
    uint32_t intValue;
    struct {
        unsigned netId          : 16;
        bool explicitlySelected :  1;
        bool protectedFromVpn   :  1;
        Permission permission   :  2;
        bool uidBillingDone     :  1;
    };
...
};
static const unsigned FWMARK_NET_ID_MASK = 0xffff;
static_assert(sizeof(Fwmark) == sizeof(uint32_t), "The entire fwmark must fit into 32 bits");

system/netd/client/NetdClient.cpp

// accept() just calls accept4(..., 0), so there's no need to handle accept() separately.
extern "C" void netdClientInitAccept4(Accept4FunctionType* function) {
    HOOK_ON_FUNC(function, libcAccept4, netdClientAccept4);
}

...

#define HOOK_ON_FUNC(remoteFunc, nativeFunc, localFunc) \
    do {                                                \
        if ((remoteFunc) && *(remoteFunc)) {            \
            (nativeFunc) = *(remoteFunc);               \
            *(remoteFunc) = (localFunc);                \
        }                                               \
    } while (false)

...

// These variables are only modified at startup (when libc.so is loaded) and never afterwards, so
// it's okay that they are read later at runtime without a lock.
Accept4FunctionType libcAccept4 = nullptr;

...

int netdClientAccept4(int sockfd, sockaddr* addr, socklen_t* addrlen, int flags) {
    int acceptedSocket = libcAccept4(sockfd, addr, addrlen, flags);
    if (acceptedSocket == -1) {
        return -1;
    }
    int family;
    if (addr) {
        family = addr->sa_family;
    } else {
        socklen_t familyLen = sizeof(family);
        if (getsockopt(acceptedSocket, SOL_SOCKET, SO_DOMAIN, &family, &familyLen) == -1) {
            return closeFdAndSetErrno(acceptedSocket, -errno);
        }
    }
    if (FwmarkClient::shouldSetFwmark(family)) {
        FwmarkCommand command = {FwmarkCommand::ON_ACCEPT, 0, 0, 0};
        if (int error = FwmarkClient().send(&command, acceptedSocket, nullptr)) {
            return closeFdAndSetErrno(acceptedSocket, error);
        }
    }
    return acceptedSocket;
}

int netdClientConnect(int sockfd, const sockaddr* addr, socklen_t addrlen) {
    const bool shouldSetFwmark = shouldMarkSocket(sockfd, addr);
    if (shouldSetFwmark) {
        FwmarkCommand command = {FwmarkCommand::ON_CONNECT, 0, 0, 0};
        int error;
        if (redirectSocketCallsIsTrue()) {
            FwmarkConnectInfo connectInfo(0, 0, addr);
            error = FwmarkClient().send(&command, sockfd, &connectInfo);
        } else {
            error = FwmarkClient().send(&command, sockfd, nullptr);
        }


    ...

Netd Server

提供INetd接口的实现（NetdNativeService），app可以远程调用实现很多网络相关的操作。负责启动各种底层服务（比如fwmark server，mdns，dnsproxy），以供framework调用。

Linux内核之上的网络管理，由netd进程提供。用户态的网络管理进程/工具，在不同的linux发行版中本就不同，由不同的应用共同构成。netd就是android的实现，一个进程全都包括了。

Fwmark Server

自动选择netId，使用SO_MARK进行标志，用于路由识别。

system/netd/server/FwmarkServer.cpp

int FwmarkServer::processClient(SocketClient* client, int* socketFd) {
...
  switch (command.cmdId) {
        case FwmarkCommand::ON_CONNECT: {
            // Called before a socket connect() happens. Set an appropriate NetId into the fwmark so
            // that the socket routes consistently over that network. Do this even if the socket
            // already has a NetId, so that calling connect() multiple times still works.
            ...
            if (!fwmark.explicitlySelected) {
                if (!fwmark.protectedFromVpn) {
                    fwmark.netId = mNetworkController->getNetworkForConnect(client->getUid());
                } else if (!mNetworkController->isVirtualNetwork(fwmark.netId)) {
                    fwmark.netId = mNetworkController->getDefaultNetwork();
                }
            }
            break;
            ...
            
  if (setsockopt(*socketFd, SOL_SOCKET, SO_MARK, &fwmark.intValue,
                   sizeof(fwmark.intValue)) == -1) {
        return -errno;
    }

    return 0;
...            

NetworkController

结果最后都转为对linux网络的操作，就是ip rule和ip route的操作，不同的netid对应不同的table，而fwmark则用于rule的规则匹配。

system/netd/server/NetworkController.h

/*
 * Keeps track of default, per-pid, and per-uid-range network selection, as
 * well as the mark associated with each network. Networks are identified
 * by netid. In all set* commands netid == 0 means "unspecified" and is
 * equivalent to clearing the mapping.
 */
class NetworkController {
    ...
    unsigned getDefaultNetwork() const;
    [[nodiscard]] int setDefaultNetwork(unsigned netId);

    unsigned getNetworkForUser(uid_t uid) const;
    unsigned getNetworkForConnect(uid_t uid) const;
    
    ...
    
    // |nexthop| can be NULL (to indicate a directly-connected route), "unreachable" (to indicate a
    // route that's blocked), "throw" (to indicate the lack of a match), or a regular IP address.
    //
    // Routes are added to tables determined by the interface, so only |interface| is actually used.
    // |netId| is given only to sanity check that the interface has the correct netId.
    [[nodiscard]] int addRoute(unsigned netId, const char* interface, const char* destination,
                               const char* nexthop, bool legacy, uid_t uid, int mtu);
                               
    ...
    

system/netd/server/NetworkController.cpp

int NetworkController::addRoute(unsigned netId, const char* interface, const char* destination,
                                const char* nexthop, bool legacy, uid_t uid, int mtu) {
    return modifyRoute(netId, interface, destination, nexthop, ROUTE_ADD, legacy, uid, mtu);
}
int NetworkController::modifyRoute(unsigned netId, const char* interface, const char* destination,
                                   const char* nexthop, enum RouteOperation op, bool legacy,
                                   uid_t uid, int mtu) {
  ...
  unsigned existingNetId = getNetworkForInterfaceLocked(interface);
  ...
  switch (op) {  
        case ROUTE_ADD:
            return RouteController::addRoute(interface, destination, nexthop, tableType, mtu,
                                             0 /* priority */);

system/netd/server/RouteController.cpp

int RouteController::addRoute(const char* interface, const char* destination, const char* nexthop,
                              TableType tableType, int mtu, int priority) {
    if (int ret = modifyRoute(RTM_NEWROUTE, NETLINK_ROUTE_CREATE_FLAGS, interface, destination,
                              nexthop, tableType, mtu, priority, false /* isLocal */)) {
        return ret;
    }
    
// Adds or removes an IPv4 or IPv6 route to the specified table.
// Returns 0 on success or negative errno on failure.
int RouteController::modifyRoute(uint16_t action, uint16_t flags, const char* interface,
                                 const char* destination, const char* nexthop, TableType tableType,
                                 int mtu, int priority, bool isLocal) {
    uint32_t table;
    switch (tableType) {
        case RouteController::INTERFACE: {
            table = getRouteTableForInterface(interface, isLocal);
    
    int ret = modifyIpRoute(action, flags, table, interface, destination, nexthop, mtu, priority);
 
int modifyIpRoute(uint16_t action, uint16_t flags, uint32_t table, const char* interface,
                  const char* destination, const char* nexthop, uint32_t mtu, uint32_t priority) {
                  
  int ret = sendNetlinkRequest(action, flags, iov, ARRAY_SIZE(iov), nullptr);

最后，我还是没能理解为什么protect不生效，没道理啊。

2024.10.10 Update:  minivtun-android已经可以使用protect。

2024.12.08 Update: 不能使用protect的原因终于找到了！因为我在调用vpnservice的protect()之前，调用了udp的connect()方法。一旦调用connect之后，linux内核就把路由查询完毕了，之后再通过protect设置fwmark已经晚了，内核不会再查询路由了！

以下是Claude-3.5-Sonnet生成的解释

Understanding the Mechanism

To understand this issue, we need to look at three key components:

UDP Connect Operation

• When you call connect() on a UDP socket, the kernel performs a route lookup
• This routing decision gets cached for subsequent send() operations
• The route is determined based on current socket attributes, including fwmark

VpnService.protect()

• Under the hood, protect() sets a special fwmark on the socket
• This fwmark tells the kernel to bypass VPN routing
• The fwmark is used during route lookup decisions

Kernel Route Caching

• Once a route is cached by connect(), it stays until the socket is disconnected
• Changing fwmark after connect() won't trigger a new route lookup
• The cached route continues to be used regardless of later fwmark changes

实际上，除了WireGuard，我还一直还同时在使用Minivtun，甚至还写了一个Rust的克隆版本。WireGuard的劣势是数据包有明显的特征很容易被识别和屏蔽，Minivtun则完全没有任何特征 。Minivtun的代码还非常简单，很容易修改。在Rust版本里，我加入了原始版本里没有的两个功能，fwmark和rebind。前者便于设置路由规则（参照wireguard），特别是默认路由。后者则在断连时，自动变换端口，这样就稳定很多。

然而，虽然WireGuard可以借助WireGuard-Wgsd进行内网穿透，Minivtun却做不到。也不是做不到，在去年上半年有感于libp2p的分布式打孔功能太弱鸡的时候，我曾经搞了一个简单的打孔库Rndz，并把Minivtun进行了改造，可以做到内网穿透了。但因为已经有了WireGuard-Wgsd，这个可以穿透的Minivtun显得很鸡肋，没用上。

我一直想要的是可以从手机访问内网的功能，特别是在使用移动网络的时候。想法由来已久，终于在上个月动手干了。App是从Android SDK的ToyVPN的例子简单改造的，使用JNI调用minivtun-rs的lib。目前已经在手机稳定跑了两天，可以在wifi和数据之间自由切换，耗电量也很低，可以一直开着。虽然代码很糙，界面也非常简陋，但是暂时够用了，呵呵。

代码在这里1，2，供折腾。