一个正在发生的范式转移

2025 年末，Andrej Karpathy 在一次访谈中说了句话，精准概括了当下的趋势：「最好的开发工具，不是给人用的，而是给 Agent 用的。」

这不是一句空话。看看今天最活跃的开发者工具生态——Claude Code、OpenAI Codex CLI、Aider、OpenHands——它们没有一个是以 GUI 为核心的。它们的交互方式是终端、管道、结构化输出。它们的第一用户不是坐在屏幕前的人类，而是另一个 AI。

这背后是一个更深层的变化：软件的目标用户正在从人类转向 Agent。

我们把这种思路叫做面向 Agent 的软件开发（Agent-Oriented Software Development）。

什么是「面向 Agent」？

传统软件的用户是人类，所以设计重点是：
- 好看的图形界面
- 直觉化的交互流程
- 减少用户认知负担

面向 Agent 的软件，用户是 AI，设计重点完全不同：
- 结构化输出：返回 JSON 而非 HTML，减少 token 浪费和解析错误
- API 优先：一切能力通过 API 暴露，不需要浏览器
- CLI 原生：命令行是 Agent 最自然的交互界面
- 可组合性：像 Unix 管道一样，每个组件做好一件事，通过标准接口串联
- 确定性：退出码、状态码、错误信息必须精确无歧义

这不是科幻。这是正在发生的事。

Linux 天生适合 Agent

如果你观察 AI Agent 的行为模式，会发现一个有趣的现象：几乎所有成功的编码代理都选择在 Linux 环境中运行。 Claude Code、Codex CLI、OpenHands、SWE-Agent，无一例外。

这不是巧合。Linux 的设计哲学天然适合 Agent：

Linux 的「一切皆文件」哲学，在 Agent 时代获得了新的意义。Agent 不需要看懂图形界面，它只需要读写文件、执行命令、解析输出。这正是 Unix/Linux 50 年来一直擅长的事。

Karpathy 曾半开玩笑地说：「Linux 就是为 Agent 准备的操作系统，只是提前了 50 年。」

CLI 优先：Agent 的母语

CLI（命令行界面）正在成为 Agent 与软件交互的标准协议。原因很简单：

1. 确定性：每个命令有明确的输入输出，不像 GUI 那样依赖视觉判断
2. 可脚本化：CLI 命令天然可以串成 pipeline
3. 低开销：不需要渲染界面，省计算资源，也省 token
4. 自文档化：--help 就是最好的 API 文档

看看今天的明星开发工具：

• Claude Code：Anthropic 出品的终端编码代理，纯 CLI 交互，支持 MCP，可以读写文件、运行命令、搜索代码——全部在终端完成
• OpenAI Codex CLI：OpenAI 的命令行编码工具，沙箱中执行，CLI 优先设计
• Aider：开源终端 AI 结对编程工具，直接在终端里与 LLM 协作编辑代码
• OpenHands：开源自主编码代理，通过终端和浏览器完成任务

这些工具的共同点：没有 GUI，不需要 GUI，Agent 直接在终端里干活。

MCP：Agent 生态的 HTTP

如果说 CLI 是 Agent 与单机软件交互的语言，那 MCP（Model Context Protocol） 就是 Agent 与外部世界沟通的标准协议。

MCP 由 Anthropic 于 2024 年 11 月发布，核心思想极其简洁：定义一个统一标准，让任何 AI Agent 能够连接任何外部工具和数据源。

┌─────────────┐     MCP      ┌──────────────┐
│  AI Agent   │ ◄──────────► │  MCP Server  │
│ (Claude,etc)│   标准协议    │ (工具/数据源) │
└─────────────┘              └──────────────┘

MCP 的关键特性：
- 双向通信：支持请求-响应和流式推送
- 工具发现：Agent 可以动态发现可用工具
- 类型安全：基于 JSON Schema 的输入输出定义
- 传输灵活：支持 stdio 和 SSE 两种传输方式

截至 2026 年 5 月，MCP 生态已有超过 1,000 个 MCP Server，覆盖数据库、文件系统、搜索引擎、代码仓库、项目管理等几乎所有开发者场景。Block（Square）、Apollo、Replit、Zed 等公司已正式接入。

MCP 对 Agent 的意义，类似于 HTTP 对 Web 的意义——它提供了一个通用的连接层，让 Agent 不需要为每个工具写定制集成。

AnySearch：Agent-Native 搜索基础设施

要理解「面向 Agent 的软件开发」，AnySearch 是一个极佳的案例。

AnySearch 把自己定位为 「AI 时代的搜索基础设施」（Search Infrastructure for the AI Era），注意这个定位——不是「搜索引擎」，而是「基础设施」。它的目标用户不是在浏览器里搜索的人类，而是需要高质量、结构化搜索结果的 AI Agent。

开源的 MCP Server 托管在 GitHub: anysearch-ai/anysearch-mcp-server，290+ stars，提供完整的搜索能力封装。

三种集成方式，覆盖所有 Agent 场景

AnySearch 提供三种 Agent 集成方式，精准覆盖了当前 Agent 生态的主要形态：

1. API 集成——最直接的方式

# 任何 Agent 框架都可以通过 HTTP 调用
response = requests.get("https://api.anysearch.com/v1/search", 
    params={"query": "Rust coding agent", "output": "json"},
    headers={"Authorization": "Bearer YOUR_KEY"})

API 返回结构化 JSON，Agent 直接消费，无需解析 HTML。这对 Agent 来说是最友好的格式——没有 DOM 解析的开销，没有广告和噪音，纯数据。

2. MCP 集成——标准协议的方式

对于支持 MCP 的 Agent（如 Claude Code、Cursor），只需配置 MCP Server：

{
  "mcpServers": {
    "anysearch": {
      "type": "streamable-http",
      "url": "https://api.anysearch.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_KEY"
      }
    }
  }
}

配置完成之后，Agent 就自动拥有了 AnySearch 的搜索能力，无需写一行代码。MCP Server 原生支持 Streamable HTTP 传输（MCP spec 2025-03-26），同时也支持通过 mcp-remote 或 supergateway 代理接入 stdio/SSE 客户端。覆盖 Claude Desktop、Cursor、VS Code Copilot、Windsurf、OpenCode、Cline 等主流 Agent 工具。

这就是 MCP 的威力——工具即插即用。

3. Skill 集成——知识注入的方式

Skill 方式将搜索能力编码为 Agent 可理解的知识单元，Agent 不需要运行时调用外部 API，而是将搜索逻辑内化为自身能力的一部分。

MCP Server 提供的四个核心工具

AnySearch 的 MCP Server 封装了四个核心能力，Agent 通过自然语言即可调用：

值得注意的是 23 个垂直领域的设计——金融（美股/港股/A股）、学术论文、网络安全（CVE）、法律判例、代码、知识产权等。Agent 不需要自己判断该搜什么网站，只需指定领域，AnySearch 自动路由到专业数据源。

Agent-Native 的设计细节

AnySearch 的 Agent-Native 设计体现在多个层面：

• 结构化输出：搜索结果以 JSON 返回，显著减少 token 浪费
• 智能意图路由：自动识别查询意图并路由到最相关的数据源，Agent 不需要手动选择搜索源
• 匿名访问：无 API Key 也可使用（低频限额），零跟踪、零遥测，隐私从架构层面保证
• 全频谱覆盖：从专业深度数据到日常广度信息，覆盖 Agent 的各类需求
• 并行批处理：单次调用执行多个独立查询，减少 Agent 的往返次数

竞品对比：传统搜索 vs Agent 搜索

一个关键问题是：Agent 为什么不能直接用现有的搜索工具？ 我们来看看当前的搜索生态格局：

Brave Search 是面向人类的传统搜索引擎，提供了 API 接口。它的核心设计仍然围绕「给人类看的搜索结果页」，返回的是网页摘要和链接，Agent 需要自行解析和筛选。

Perplexity 是 AI 搜索领域的明星产品，但它的设计目标是「替人类搜索并总结」——用户输入问题，Perplexity 返回一个漂亮的总结页面。Perplexity 是一个终端产品，不是一个基础设施。它没有 MCP 支持，没有 CLI 集成，不提供 Agent 可编程的结构化输出。Agent 想用 Perplexity？对不起，它不是给你用的。

Parallel 是另一个 AI 搜索 API 提供者，比 Brave 更接近 Agent 需求，但在准确率和延迟上仍有差距。

根据 AnySearch 官方基准测试（基于 Frames、FreshQA、WebwalkerQA 三个数据集，共 300 个问题，使用 GLM-5.1 作为 LLM）：

在真实场景中，差距更明显。以「安全工程师分析告警日志」为例，AnySearch 能交叉验证多个专业情报源并给出可操作的响应方案，得分 9.5；Brave 虽能得出正确结论，但依赖公开平台，需要人工二次验证，得分 8.2。在「商务出行实时决策」场景中，差距更大——AnySearch 8.0 vs Brave 5.5，主要因为 Brave 在航班查询上直接失败，且交通信息包含事实错误。

这些数据说明了一个关键事实：Agent 需要的不是更好的搜索引擎，而是为 Agent 设计的搜索基础设施。

人类可以容忍搜索结果页面有广告、有多余信息、需要二次筛选，但 Agent 不能——每一个多余的 token 都是成本，每一次解析错误都是失败。Perplexity 做得再好，它是给人类用的搜索产品；AnySearch 做的是给 Agent 用的搜索协议。这是两个完全不同的赛道。

面向 Agent 的设计原则

综合以上案例和趋势，我们可以提炼出面向 Agent 的软件设计的核心原则：

原则一：结构化优于可视化

软件应该默认返回结构化数据（JSON、CSV、XML），而不是渲染好的页面。人类可以看表格，Agent 需要数组。

原则二：CLI 优先于 GUI

先有 CLI，再考虑 GUI。CLI 是 Agent 的原生接口，GUI 是人类的附加需求。

原则三：可组合优于一体化

每个组件做好一件事，通过标准接口（pipe、MCP、API）组合。不要做一个臃肿的「万能工具」，要做一堆精致的「螺丝刀」。

原则四：确定性优于智能

对于 Agent 消费的接口，确定性比「智能」更重要。返回精确的错误码，不要返回一个模糊的「出了点问题」。

原则五：协议优于定制

用 MCP、OpenAPI 等标准协议，而不是为每个 Agent 写定制集成。HTTP 赢了不是因为最快，而是因为最标准。MCP 会赢也是同理。

未来的软件开发者需要思考什么？

如果你是软件开发者，现在就需要开始思考：

1. 你的软件有 CLI 吗？ 如果没有，Agent 用不了。
2. 你的 API 返回结构化数据吗？ 如果返回 HTML，Agent 需要额外解析。
3. 你支持 MCP 吗？ 这正在成为 Agent 生态的连接标准。
4. 你的错误处理足够精确吗？ Agent 依赖退出码和错误信息做决策。
5. 你的文档是给谁看的？ 如果只有人类能看懂，Agent 也用不了。

这不是「未来趋势」，这是正在发生的现实。2026 年，越来越多的软件会同时面向两种用户：人类和 Agent。而面向 Agent 的那一面，正在变得更重要。

参考链接：
- AnySearch — AI Search Infrastructure for Agents
- AnySearch MCP Server — GitHub
- MCP (Model Context Protocol) Specification
- Claude Code — Anthropic
- Aider — AI Pair Programming in Terminal
- OpenHands — Open Source AI Software Engineer
- Perplexity AI
- Brave Search API