Notes Wiki

Agent-Native-Infrastructure

6 min read

Agent-Native Infrastructure

创建时间： 2026-04-30 来源： [[sources/Andrej Karpathy From Vibe Coding to Agentic Engineering - 逐字稿]] 相关： Software-3.0，Harness-Engineering，Agent-First-Repository-Design，Vibe-Coding-to-Agentic-Engineering，Agent-Readiness，AI-Native-Interaction

核心问题：一切仍为人类设计

Karpathy 指出的根本矛盾：

“Everything is still fundamentally written for humans and has to be moved around.”

当前技术栈的每一层——框架文档、库文档、部署平台、DNS 配置——都是为人类阅读和手动操作设计的。这对于 agent 驱动的开发模式来说是完全错误的抽象层。

Karpathy 的典型痛点

“Every time I’m told ‘go to this URL,’ it’s just like, ah, you know.”

他最讨厌的事：文档告诉他去做什么。“I don’t want to do anything. What is the thing I should copy-paste to my agent?”

写 MenuGen 的代码不是最难的——部署才是：

  • 在 Vercel 上部署
  • 串联各种第三方服务
  • 进入每个服务的设置菜单
  • 配置 DNS

这些步骤消耗的时间和精力远超编码本身。理想状态：给 LLM 一个 prompt “build MenuGen and deploy it”，不需要人类碰任何东西。

Sensors and Actuators 模型

Karpathy 用传感器和执行器的类比来描述 agent-native 架构：

“How do we decompose the workloads that need to happen into fundamentally sensors over the world, actuators over the world?”

  • Sensors（传感器）：Agent 感知世界的接口——读取环境状态、文件系统、API 响应、日志
  • Actuators（执行器）：Agent 作用于世界的接口——写入文件、调用 API、部署服务、配置 DNS
  • 数据结构要对 LLM 可读（legible to LLMs）——不是 JSON API 文档，而是 agent 能直接理解和操作的数据格式

Agent-First 设计原则

1. 文档写给 Agent，不是人

当前："Go to this URL, click settings, scroll down to..."
应该：一段可以直接粘贴给 agent 的文本，agent 能自主完成所有步骤

2. 部署应端到端自动化

Karpathy 的测试标准：

“I could give a prompt to an LLM ‘build MenuGen’ and then I didn’t have to touch anything and it’s deployed in that same way on the internet.”

如果一个产品/平台/框架需要人类手动配置才能从代码变成线上运行的服务，它就是尚未 agent-native。

3. 将工作流分解为 sensor/actuator 原语

  • 每种操作应暴露为 agent 可直接调用的 actuator
  • 每种状态应暴露为 agent 可直接读取的 sensor
  • 人类 UI 是第二位的——agent 接口才是第一位的

Agent-to-Agent 通信

Karpathy 的终极愿景：

“I’ll have my agent talk to your agent to figure out some of the details of our meetings.”

这需要全新的基础设施层：

  • Agent 间的标准化通信协议
  • Agent 的身份和权限体系
  • 人类审批的中间检查点
  • 跨组织的 agent 协作框架

当前信号：OpenClaw 安装作为 Agent-Native 雏形

OpenClaw 的安装方式已经是 agent-native 思维的体现：

  • 不是 shell 脚本（Software 1.0），而是一段给 agent 的文字描述（Software 3.0）
  • Agent 自己检查环境、调试问题、适配平台
  • 见 Software-3.0 中的案例 2

与 Harness Engineering 的关系

Agent-Native Infrastructure 是 Harness-Engineering 的上游依赖：

Harness EngineeringAgent-Native Infrastructure
为 agent 设计工作环境为 agent 设计基础设施接口
关注 agent 如何协作、如何保持质量关注外部服务如何被 agent 调用
AGENTS.md、sprint contract、evalAPI、DNS、部署平台、数据库的 agent 接口

两者互补：Harness Engineering 解决”agent 怎么工作”，Agent-Native Infrastructure 解决”世界怎么对 agent 开放”。

开放问题

  • 当前哪些平台/服务已经提供了 agent-first 的接口？哪些还完全是人-first？ → 已量化：见 Agent-Readiness，Ora 对 8,359 个产品的五层深度扫描——99% 未就绪，中位数 37/100，73% 为 D 或 F。具体协议采纳数据（sitemap 69% 到 x402 0%）提供了精确的现状画像。
  • Agent-to-agent 通信协议是否需要标准化（类似 HTTP 之于浏览器），还是每家自建？→ ACP 采纳率约 13%，A2A Agent Card 约 12%，协议标准化仍在早期但已有明确方向。
  • 当 agent 可以自主配置 DNS、购买域名、开通云服务时，安全和权限边界在哪里？

参考资料

Graph View

Backlinks