智能体工具与软件开发实践的变迁

博途PLC工程智能体 | AI智能体博途网关 | 博途PLC程序知识图谱 | 梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 逆向生成程序块文档 | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI

AI 编程智能体正把软件开发从逐行自动补全，推向把完整任务委托给能够读取、编辑、运行和测试代码的语言模型程序。本文详细介绍三个开源、MIT 许可的工具，它们代表了这一新栈中不同的层次。

OpenCode 是一个功能齐全的编程智能体，采用客户端/服务器架构，内置五个智能体、十三个内置工具、基于规则的权限系统，并可与编辑器、GitHub 以及 34 个内置语言服务器集成。

Pi 是一个刻意极简的智能体运行框架（agent harness）：四个工具、不到 1,000 token 的系统提示词、树状结构的会话，以及一套扩展系统——智能体可以通过该系统重写自己的工具。

Orca 是一个智能体开发环境（ADE），可并行运行许多第三方智能体（包括 OpenCode 和 Pi），每个智能体运行在隔离的 git worktree 中，并提供评审、移动端监管和可脚本化的 CLI。

对每个工具，我们依据一手资料和 2026 年 9 月 23 日获取的注册表数据，描述其起源、设计理念、架构和工作流。随后我们分析这些工具如何改变软件开发，识别出七种转变：从亲自编写到 specify（声明意图）与评审；并行探索成为工作单位；上下文工程成为开发者技能；智能体成为可编程基础设施；自我修改的工具；与模型供应商解耦；以及新的安全与治理职责。我们把这些转变与已发表的实证证据联系起来，而这些证据好坏参半：一项对照实验发现受限任务提速 55.8%，而一项针对有经验的开源开发者的随机试验则发现速度下降 19%。我们的结论是：这些工具更可靠地改变的是开发者精力的去向，而非所需的精力总量，并提出开放的研究问题。

1、引言

软件开发正在经历自集成开发环境（IDE）以来最大规模的工具变革。2025 年 Stack Overflow 开发者调查显示，84% 的受访者正在使用或计划使用 AI 工具，一年前这一比例为 76% [42]。Google 2025 年的 DORA 研究基于近 5,000 名技术人员，报告 AI 采用率达 90% [43]。自主智能体的采用则更早：在同一份 Stack Overflow 调查中，14.1% 的受访者每天使用 AI 智能体，而 37.9% 打算不使用它们 [42]。

第一代 AI 辅助是编辑器内的自动补全。当前这一代是编程智能体：一种程序，它赋予大语言模型（LLM）读取文件、编辑代码和执行命令的工具，然后循环运行直到任务完成。SWE-agent 等研究系统表明，这种智能体-计算机接口（agent-computer interface）的设计强烈影响结果 [41]。SWE-bench 等基准测试则把真实的 GitHub issue 变成了标准测试 [40]。

随着智能体走向成熟，工具栈开始分层。一层是智能体运行框架（agent harness）：循环、工具、提示词和上下文管理。另一层同时监管多个智能体、隔离它们的工作，并把它们的输出路由给人类评审。本文介绍三个开源项目，它们共同覆盖了这些层次：

• OpenCode [23][24]，一个功能齐全的编程智能体，提供终端 UI、桌面应用、IDE 集成和无头（headless）服务器。

• Pi [9][10]，一个极简、可自我扩展的智能体运行框架和 TypeScript 工具包。

• Orca [1][2]，一个智能体开发环境，并行运行多个 CLI 智能体，每个智能体拥有自己的 git worktree。

我们提出四个研究问题：

• RQ1. 每个工具做什么，它是如何构建的？

• RQ2. 这些工具在设计理念上有何不同？

• RQ3. 在可测量、可验证的属性上它们如何比较？

• RQ4. 这类工具如何改变软件开发的实践？

我们的贡献包括：对三个工具截至 2026 年 9 月 23 日状态的详细、有出处的描述（第 3–5 节），结构化对比（第 6 节），以及基于已发表证据、分析其对软件开发影响的章节（第 7 节）。第 2 节介绍背景与方法，第 8 节讨论局限，第 9 节作结。

2、背景与方法

2.1 从自动补全到智能体

关于 AI 辅助编程的早期证据来自自动补全工具。在一项对照实验中，使用 GitHub Copilot 的开发者用 JavaScript 实现一个 HTTP 服务器的速度比对照组快 55.8% [38]。自动补全让开发者仍然是每一行代码的作者。

智能体改变了这种关系。SWE-bench 评估模型能否解决真实 issue，它包含来自 12 个热门 Python 仓库的 2,294 个任务实例，发表时最好的模型解决了其中 1.96% [40]。SWE-agent 引入了智能体-计算机接口（ACI）这一术语，主张 LLM 智能体是一种新型用户，其工具必须专门为它们设计，并在 SWE-bench 上达到 12.5% 的 pass@1 [41]。本文研究的三个工具都是这一思想的实践后继者，它们对"智能体的接口应当多丰富"做出了不同的选择。

2.2 使能标准

这三个工具建立在少量开放约定之上。表 1 对它们做了总结。

表 1. 工具所使用的标准与约定。

2.3 方法

我们只使用一手资料：官方仓库与源文件、项目网站与文档、作者博客、Y Combinator 公司页面、同行评审或预印本研究，以及机器可读的注册表 API。任何数字都没有使用第三方评测或聚合网站。文档尽可能以其在各仓库中的源码形式阅读。

定量仓库数据于 2026 年 9 月 23 日从以下端点获取：

表 2. 定量指标的数据来源。

对 earendil-works/pi 和 anomalyco/opencode 运行了相同的查询。贡献者计数包含匿名（仅邮箱）提交者，因此与 GitHub 仓库页面上显示的总数不同。Star 和下载量每天都在变化，应当视为快照。

3、Orca：一个智能体开发环境

3.1 起源

Orca 由 Stably AI 构建，这是一家位于旧金山、隶属 Y Combinator 2022 冬季批次的公司，由 Jinjing Liang（CEO）和 Neil Parker 创立 [3]。Y Combinator 将其描述为"MIT 开源的基于终端的智能体编排器"以及"为同时运行 10 到 100 个编程智能体的工程师打造的 ADE" [3]。仓库创建于 2026 年 3 月 17 日。截至 2026 年 9 月 23 日，它有 75,830 个 star，最新版本为 v1.4.207，发布于 2026 年 9 月 22 日 [1][48]。README 的标语是"The AI Orchestrator for 100x builders"（为百倍效能构建者打造的 AI 编排器）[1]。

3.2 设计理念

Orca 的核心决策是不去构建一个智能体。其文档称它"运行你已经在用的智能体——自带你的 Claude、Codex 或 OpenCode 订阅" [2]。README 表示它适用于"任何 CLI 智能体——只要它能在终端里运行，它就能在 Orca 里运行" [1]。它列出了 31 个智能体，包括 Claude Code、Codex、Cursor、GitHub Copilot、Antigravity、OpenCode、Pi、Goose、Cline 和 Qwen Code [1]。

这使 Orca 成为一个监管者。它假设开发者的瓶颈不再是单个智能体的能力，而是人类同时运行、观察和评审多个智能体的能力。这个环境围绕任务而非文件组织。用文档的话说："每个任务都有自己的 git worktree、自己的智能体终端和自己的浏览器标签页" [2]。

3.3 架构

Orca 是一个基于 Electron 的桌面应用。其 package.json 声明了 Electron 43.7.0、React 19、Monaco 编辑器（VS Code 的编辑器组件）、用于终端的 xterm.js 以及用于伪终端的 node-pty [4]。它发布了 macOS、Windows 和 Linux 版本 [2]。每个智能体都作为普通 CLI 进程运行在 Orca 拥有的终端内。因此 Orca 不需要每个智能体供应商提供集成 API——任何带命令行界面的东西都可以被托管。

执行不必在本地。智能体可以"远程运行——通过 SSH、自托管的 Orca 服务器，或按需分配的虚拟机" [2]，无头服务器可以用 orca serve 启动 [1]。文档强调 Orca"不是托管 VPS 产品"，运行在用户控制的机器上 [2]。仓库中还有一个独立的中继（relay），把移动应用与桌面主机配对 [1]。

3.4 worktree 生命周期

git worktree 是附加在同一仓库上的第二个工作目录，让开发者"同时检出多个分支" [44]。Orca 把 worktree 作为智能体隔离的单位。其文档描述的生命周期有五个阶段 [5]：

1. 创建（Create）。 开发者为任务命名并选择起点。"Branch from"控件接受仓库的基础 ref、另一个本地分支、特定的 commit SHA 或远程分支 [5]。分支名派生自工作区名称，或来自关联的 GitHub PR 或 Linear/Jira issue [5]。git fetch 和 git worktree add 步骤在后台运行，以保持界面响应 [5]。
2. 工作（Work）。 所选智能体作为新 worktree 的第一个标签页启动 [5]。
3. 评审（Review）。 diff 视图把 worktree 与其起点进行比较 [5]。开发者可以对单行 diff 添加评论，并把评论发回给智能体 [1]。
4. 交付（Ship）。 在 Orca 内部提交、推送并创建 pull request [5]。
5. 归档或删除。 "一键移除 worktree 和分支" [5]。如果分支可能仍持有未合并的提交，Orca 可以先提供一个评审步骤 [5]。

新建的 worktree 并非空依赖起步。Orca 可以从主检出共享路径（在 macOS 上尽可能采用写时复制克隆，否则使用符号链接）。它可以为 orca.yaml 中 worktree.sharedDirectories 下列出的 gitignored 目录创建符号链接，也可以复制 .worktreeinclude 文件中列出的文件 [5]。文档总结了其好处："并行的智能体是安全的——它们绝不会互相踩踏对方的文件" [5]。

3.5 监管多个智能体

Orca 增加了若干面向监管而非亲自编写的功能：

• 扇出（Fan-out）。 一个提示词可以发送给五个智能体，各自在自己的 worktree 中，开发者可以"比较结果并合并优胜者" [1]。

• 用量跟踪。 Orca"读取 Claude Code、Codex、Gemini、OpenCode、Kimi Code 和 MiniMax 的本地用量状态"并在状态栏显示，在达到速率限制的 80% 时告警。开发者可以在已配置的账户之间切换 [8]。

• 通知。 当智能体完成或需要注意时，Orca 会发出信号，会话线程可以被标记为未读 [1]。

• 移动伴侣。 iOS 和 Android 应用通过一次性验证码与桌面端配对，可选择经由 Orca Relay。在手机上，开发者可以"查看每个 worktree、它的智能体及其当前状态（工作中 / 已完成 / 等待输入）"，并在智能体等待输入时"发送简短回复（继续、是、自由文本）" [7]。桌面端仍然是"事实来源" [7]。

3.6 Orca CLI：智能体驱动环境

orca 命令是"从任意 shell 对正在运行的 Orca 编辑器进行脚本化控制的命令行界面" [6]。由于智能体同样运行 shell，CLI 让智能体可以驱动 Orca 本身：创建 worktree、读取其他终端或控制浏览器。表 3 列出了命令组。智能体可以通过 npx skills add <https://github.com/stablyai/orca> 以技能形式学习该 CLI——技能 orca-cli [6]。

表 3. Orca CLI 命令组 [6]。

浏览器控制遵循"快照-交互-再快照循环"：orca snapshot --json 返回诸如 @e1 之类的元素引用，orca click 和 orca fill 随后对其操作 [6]。这让智能体可以在真实的 Chromium 窗口中检查自己的前端改动。

3.7 功能概要

表 4. Orca 的主要功能。

Orca 可以从 onorca.dev/download 下载安装，也可以用 Homebrew（brew install --cask stablyai/orca/orca）或从 AUR（stably-orca-bin）安装 [1]。

4、Pi：极简、可自我扩展的智能体运行框架

4.1 起源

Pi 由 Mario Zechner（GitHub 用户名 badlogic）创建。monorepo 创建于 2025 年 8 月 9 日，名为 badlogic/pi-mono [9][13]。在 2025 年 11 月 30 日的一篇文章中，Zechner 解释了他构建它的原因 [11]。他写道，现有的运行框架已经变得复杂、在版本之间行为各异，而且很难看清什么进入了模型的上下文。他想要一个文档清晰的会话格式，以及构建替代用户界面的简单方式 [11]。

Armin Ronacher 在 2026 年 1 月 31 日把 Pi 描述为 OpenClaw 内部的最小智能体 [12]。2026 年 4 月 8 日，Zechner 宣布加入由 Ronacher 联合创办的 Earendil 公司，并把 Pi 一并带去 [13][14]。仓库迁移到了 earendil-works/pi。Zechner 表示核心代码"MIT，永远。没有商量余地"，并且他与 Earendil 的联合创始人一起继续负责 Pi 的决策 [13][14]。截至 2026 年 9 月 23 日，该仓库有 108,622 个 star，最新版本为 v0.87.1 [9][48]。

4.2 设计理念

Pi 的定义既来自它包含什么，也来自它省略什么。它的编程智能体有四个内置工具：read、write、edit 和 bash [11][12]。Zechner 报告说，系统提示词和工具定义加起来"低于 1000 token" [11]。理由是读取、写入、编辑和运行代码覆盖了大部分编程工作，而一个小而稳定的提示词能让模型的行为可预测、可检查。

Pi 刻意排除了其他智能体中常见的若干功能 [11]：

• MCP。 Zechner 认为 MCP 服务器"对大多数场景来说是杀鸡用牛刀"，因为工具描述会消耗上下文。他更喜欢带 README 文件的命令行工具，智能体在需要时阅读它们。

• 内置子智能体。 他认为隐藏的子智能体会降低可观测性。智能体仍然可以通过 bash 显式启动另一个 Pi 进程。

• 计划模式（Plan mode）。 计划应当是普通的 Markdown 文件，跨会话持久存在并可共享。

• 权限提示。 Pi 默认"YOLO"运行（即默认不询问直接执行）。

任何被省略的东西，都可以由用户或智能体自己以扩展的形式加回来。

4.3 智能体循环与上下文

Pi 的文档精确描述了这个循环 [15]。提交的消息加入会话的活动分支。Pi 由系统提示词、活动分支、可用工具和模型设置构建一个请求，发送给所选的提供商。提供商流式返回文本和工具调用；Pi 执行每个工具调用并记录结果。这就是一轮（turn）。如果工具结果或排队的消息需要另一次模型请求，就开始新的一轮；否则运行结束 [15]。

Pi 区分两类用户插话。引导（steering）消息在当前助手轮次之后进入，而后续（follow-up）消息则等待智能体完成其挂起的工作 [15]。系统提示词由基础指令和被发现的上下文文件（如 AGENTS.md 和 CLAUDE.md）组装而成 [15][22]。技能描述始终存在，但技能的完整指令只在任务需要时才加载 [15]。

4.4 会话即树

大多数智能体把对话存为列表，Pi 把它存为树。"会话中的消息和事件构成一棵树，穿过这棵树的每条路径就是一个分支" [15]。会话以 JSONL 文件保存，每个条目都有一个 ID 和一个父条目 [15]。表 5 展示了三种分支操作。

表 5. Pi 会话分支操作 [16]。

当开发者离开一个分支时，Pi 可以总结它并把摘要附到新分支上，这样有用的发现无需完整记录也能保留下来 [16]。当上下文接近模型上限时，Pi 会自动压缩。当上下文 token 超过上下文窗口减去一个预留量时触发压缩，预留量默认为 16,384 token [17]。它插入一个摘要条目，但原始条目仍保留在会话文件中 [15][17]。会话可以导出为 HTML 或 JSONL，也可以通过查看器链接共享 [16]。

4.5 扩展性：扩展、技能、模板与包

Pi 增长的主要机制是扩展（extension）。"扩展是为 Pi 添加可执行行为的 TypeScript 模块" [18]。它们通过 jiti 加载，因此不需要单独的编译步骤 [18]。一个扩展导出一个工厂函数，接收一个 ExtensionAPI 对象。表 6 列出了其主要集成点。

表 6. Pi 扩展 API 的主要集成点 [18]。

扩展接收从 before_agent_start 开始，经过模型、消息和工具事件，到 agent_end，再接 agent_before_settle 和 agent_settled 的生命周期事件 [18]。文档列出的典型用途包括添加工具、保护路径、确认危险命令和显示状态 [18]。Ronacher 强调了两个特性：扩展可以把状态持久化到会话中；热重载让智能体"写代码、重载、测试，循环往复，直到扩展真正可用" [12]。实践中，Pi 用户常常让 Pi 自己构建它所缺失的功能。

三种更轻量的资源类型对扩展形成补充。**技能（Skills）**遵循 Agent Skills 规范：一个包含 SKILL.md 文件以及可选脚本、参考资料和资源的目录 [19]。提示词模板在编辑器中展开可复用文本，主题设置终端颜色 [15]。Pi 包把所有这些打包，通过 npm 或 git 分发，例如 pi install npm:@example/pi-tools@1.0.0。可以用 pi -e 单次试运行一个包 [20]。

4.6 界面、提供商与包家族

Pi 提供四种共享同一智能体和会话机制的界面 [15]：

• 交互模式，即终端 UI。

• 打印模式，运行一个提示词并写出最终答案。

• JSON 模式，以 JSONL 流式传输智能体事件。

• RPC 模式，在标准输入上接受 JSONL 命令，另有进程内 TypeScript SDK。

模型访问是多提供商的。/login 命令通过 OAuth 或 API key 连接提供商 [21]。文档列出了 31 个只需一个 API key 环境变量的提供商，其中包括 Anthropic、OpenAI、Google Gemini、GitHub Copilot、Mistral、Groq、xAI、OpenRouter 和 DeepSeek，以及 Amazon Bedrock 和 Google Vertex AI 等云提供商 [21]。

monorepo 把 Pi 作为一族 npm 包发布（表 7）。开发者可以在 pi-ai 和 pi-agent-core 之上构建自己的智能体，无需使用 Pi CLI。

表 7. Pi monorepo 中的包 [9]。

4.7 安全模型与项目实践

Pi 对其安全模型直言不讳。它"不会在每次工具调用前请求批准"，并以启动它的账户的操作系统权限运行 [22]。文档警告说，文件、注释和命令输出"可以通过提示注入操纵模型" [22]。项目信任（project-trust）步骤控制一个文件夹是否可以加载自己的设置、扩展和包，但它"不为工具调用提供沙箱" [22]。要获得真正的隔离，README 建议在 Docker 中、在策略控制的沙箱中运行 Pi，或使用 micro-VM 扩展 [9]。

该项目还执行严格的供应链规则。直接依赖被固定到精确版本，npm 解析避免同日发布的版本（min-release-age=2），发布的 CLI 附带 npm-shrinkwrap.json [9]。新贡献者的 issue 和 pull request 默认会被自动关闭，并由维护者每天审查 [9]。Zechner 把他自己的 Pi 工作会话作为开放数据集发布在 Hugging Face 上，并邀请其他用户分享他们的会话 [9]。

Pi 的安装命令为 npm install -g --ignore-scripts @earendil-works/pi-coding-agent（需 Node.js 22.19 或更新版本），或 curl -fsSL <https://pi.dev/install.sh> | sh [10]。文档位于 pi.dev/docs/latest。

5、OpenCode：与提供商无关的编程智能体

5.1 起源

OpenCode 由 Anomaly 开发，这是 SST serverless 框架背后的多伦多团队。Y Combinator 把它列在 2021 冬季批次，创始人为 Jay V 和 Frank Wang [36]。仓库现为 anomalyco/opencode，创建于 2025 年 4 月 30 日；原来的 sst/opencode 路径会重定向到此 [23][48]。截至 2026 年 9 月 23 日，它有 209,481 个 star，最新版本为 v1.18.32 [23][48]。项目网站报告月活开发者 1,600 万 [24]；我们无法独立核实这一数字。

这个名字还有另一段不相关的历史。另一个基于 Go 的终端智能体也曾以 opencode-ai/opencode 的名义发布。该仓库已归档，其 README 表示项目"已以 Crush 的名义在 Charm 团队下继续" [37]。本文只覆盖 Anomaly 的项目。

5.2 设计理念

Pi 追求极简，OpenCode 则追求完备。它的目标是一个开箱即用的完整智能体：无需定制即可良好工作、不绑定单一模型供应商、可以嵌入到任何地方。规划、代码库探索、依赖研究和语言服务器反馈等常见工作流都以内置智能体和工具的形式提供。安全性由可配置的权限系统处理，而不是留给用户的沙箱。

5.3 客户端/服务器架构

OpenCode 把智能体与其界面分离。"当你运行 opencode 时，它会启动一个 TUI 和一个服务器。TUI 是与服务器对话的客户端" [26]。opencode serve 启动一个无头服务器，默认监听 127.0.0.1:4096，并在 /doc 发布 OpenAPI 3.1 规范 [26]。同一个服务器还支持桌面应用（测试版）、IDE 集成、Web 界面和 JavaScript SDK [23][25]。

代码库是运行在 Bun 运行时上的 TypeScript [23]。工作区依赖目录中，界面使用 SolidJS 和 OpenTUI，HTTP 服务器使用 Hono，模型访问使用 Vercel AI SDK（ai），另有 Effect，以及配合 SQLite 的 Drizzle ORM [50]。通过 Agent Client Protocol，opencode acp 把 OpenCode 作为子进程运行，通过标准输入输出进行 JSON-RPC 通信，因此 Zed 等兼容 ACP 的编辑器可以托管它 [34]。

5.4 智能体

OpenCode 附带两个主智能体和三个子智能体（表 8）。主智能体用 Tab 键切换；子智能体由主智能体调用，或用 @ 提及 [27]。

表 8. OpenCode 内置智能体 [27]。

开发者可以用自定义提示词、模型和工具访问权限定义自己的智能体 [27]。

5.5 工具与权限

OpenCode 有 13 个内置工具（表 9）。"默认情况下，所有工具都已启用，运行无需许可" [28]。行为随后由权限配置塑造。

表 9. OpenCode 内置工具 [28]。

每条权限规则解析为"allow（允许）"、"ask（询问）"或"deny（拒绝）"，可以用 * 全局设置，并支持诸如 mymcp_* 的通配符：让某个 MCP 服务器的所有工具都"ask" [28][29]。--auto 标志会批准任何未被显式拒绝的请求；显式拒绝仍然生效 [29]。

5.6 上下文：规则与语言服务器

OpenCode 从 AGENTS.md 文件读取项目指令 [30]。/init 命令扫描仓库，可能会问几个有针对性的问题，然后写出或更新 AGENTS.md，内容包括构建、lint 和测试命令、不明显的架构以及项目约定。文档建议把这个文件提交到 git [30]。

OpenCode 与 Language Server Protocol 服务器集成，"把诊断信息作为给智能体的反馈" [31]。文档列出了 34 个内置服务器，涵盖从 C/C++（clangd）和 Go（gopls）到 Java（jdtls）、Haskell、OCaml 和 Nix 等语言 [31]。编辑之后，编译器和 linter 的诊断信息无需单独的构建步骤即可回流到模型。

5.7 扩展性与集成

OpenCode 通过几种方式扩展：

• 自定义工具和 MCP 服务器添加新的、可供模型调用的操作 [28]。

• 插件是从 .opencode/plugins/、~/.config/opencode/plugins/ 或配置中指定的 npm 包加载的 JavaScript 或 TypeScript 模块。它们挂接到事件上，并可以添加自定义工具 [32]。

• GitHub 集成。 执行 opencode github install 之后，在 issue 或 pull request 评论中提及 /opencode 或 /oc，就会在仓库的 GitHub Actions 运行器中运行 OpenCode。它可以对 issue 进行分类，或者在新分支上修复它并创建 pull request [33]。GitLab 集成也存在 [25]。

• 会话共享。 /share 创建一个形如 opncd.ai/s/ 的公开链接。共享默认是手动的，可以设置为自动或禁用 [35]。

OpenCode 与提供商无关。其网站称通过 Models.dev 支持"75+"家 LLM 提供商（包括本地模型），并支持用 GitHub Copilot 和 ChatGPT Plus/Pro 账户登录 [24]。Anomaly 还提供一个可选的精选模型服务 OpenCode Zen [24]。网站声明 OpenCode"不会存储你的任何代码或上下文数据" [24]。

OpenCode 的安装方式：curl -fsSL <https://opencode.ai/install> | bash、npm i -g opencode-ai@latest、Homebrew、Scoop、Chocolatey、pacman、mise 或 Nix [23]。

6、对比分析

三个工具占据不同的层次。Orca 编排智能体；OpenCode 和 Pi 则是 Orca 可以运行的智能体。表 10 对比了它们的设计，表 11 给出仓库和包的指标。

表 10. 设计对比（出处见第 3–5 节）。

表 11. 仓库与包指标，2026 年 9 月 23 日获取 [48][49]。

Pi 的下载数字不含其迁移前的包 @mariozechner/pi-coding-agent，该包同期另有 2,666,043 次下载 [49]。npm 计数包含 CI 运行等自动化安装，因此它衡量的是分发量，而非独立用户数。

有两处对比格外突出。第一，OpenCode 和 Pi 体现了对 SWE-agent [41] 所提出的智能体-计算机接口问题的相反回答。OpenCode 给模型一个丰富、专用的接口（13 个工具、五个智能体、语言服务器反馈）；Pi 给它一个极简、通用的接口，依赖模型在需要时自行组合 bash 命令并编写新工具。第二，Orca 表明，一旦智能体共享了终端这个共同接口，竞争前沿就会上移到编排与评审这一层。

7、这些工具如何改变软件开发

本节回应 RQ4。我们识别出三个工具使之成为可能或加以强化的七种转变。对每一种，我们描述工具中的机制，并联系现有证据。表 12 对此做了总结。

表 12. 软件开发实践的七种转变。

7.1 从亲自编写代码到声明意图并评审

在自动补全下，开发者仍然亲手写每一行。在智能体下，开发者描述一个预期结果并评判产出。Orca 的生命周期（创建、工作、评审、交付）把评审放在开发者工作的中心，其行级 diff 批注把评审意见直接变成给智能体的指令 [1][5]。OpenCode 的 Plan 智能体把分析与改动分开，让开发者在任何文件被编辑之前先就方案达成一致 [27]。

这种转变对生产力的影响尚无定论。在一项有限的全新任务上，Copilot 用户完成速度快了 55.8% [38]。相比之下，METR 对 16 位有经验的开源开发者在其各自成熟仓库中完成 246 项真实任务的随机对照试验发现：允许使用 2025 年初的 AI 工具使完成时间增加了 19% [39]。这些开发者原本预期提速 24%，事后仍认为自己快了 20% [39]。感知速度与实测速度之间的差距表明，声明意图、等待和评审这些新工作很容易被低估。像 Orca 所尝试的那样，让评审更快、更结构化的工具，针对的正是这项成本。

7.2 并行探索成为工作单位

传统开发在很大程度上是串行的：一个开发者、一个分支、一次尝试。worktree 隔离移除了同时进行多次尝试的主要技术障碍。Orca 的文档描述了把一个提示词发给五个智能体并合并最佳结果的做法 [1]。OpenCode 的 General 子智能体被描述为"并行运行多个工作单元"的方式 [27]。Pi 的会话树让单个开发者可以对对话分支，去探索一种替代方案而不丢失原始路径 [16]。

这改变了实验的经济性。当第二次尝试耗费的是算力而非开发者的时间时，尝试多种设计并加以比较就变得理性。限制因素变成开发者评审的能力——这正是 Orca 在通知、状态视图和移动监管上投入的原因 [7][8]。

7.3 上下文工程成为开发者技能

智能体只知道其上下文窗口里的内容。因此，三个工具都推动开发者把项目知识显式化、机器可读化。OpenCode 的 /init 写出一个 AGENTS.md 文件，包含构建命令、架构说明和约定，文档建议把它提交到 git [30]。AGENTS.md 格式据报告已在超过 60,000 个开源项目中使用 [47]。技能把只在需要时加载的流程打包；Pi 和 OpenCode 都支持技能，Orca 则用一个技能教智能体使用它的 CLI [6][19][28]。

Pi 让上下文管理格外可见。它在页脚显示上下文用量，把较旧的历史压缩为摘要，并在开发者导航会话树时总结被放弃的分支 [16][17]。Zechner 关于低于 1,000 token 提示词的论证本身就是一种上下文工程论证：固定指令的每一个 token 都是无法用于任务的 token [11]。对开发者而言，文档从对新成员的礼貌，转变为直接影响自动化工作质量的输入。

7.4 智能体成为可编程基础设施

当智能体暴露一个 API 时，它可以嵌入到任何已经运行代码的地方。OpenCode 的无头服务器发布 OpenAPI 3.1 规范 [26]。其 GitHub 集成在有人于 issue 中评论 /opencode 时，在 GitHub Actions 中运行该智能体，并可以返回一个 pull request [33]。Pi 提供 print、JSON 和 RPC 模式以及进程内 SDK，其更底层的包可用于构建完全不同的智能体 [9][15]。Orca CLI 让智能体可以创建 worktree、读取其他智能体的终端并驱动浏览器 [6]。

实际结果是智能体加入了软件交付流水线。issue 分类、初稿修复、依赖研究和前端验证可以由事件触发，而不是由键盘前的开发者触发。DORA 2025 年的研究把 AI 描述为"一面镜子和一个倍增器"：它在凝聚力强的组织中提升效率，在割裂的组织中暴露弱点 [43]。自动化智能体很可能放大一条流水线已有的任何测试与评审纪律。

7.5 自我修改的工具

在 Pi 中，获得缺失功能的最快方式往往是让智能体来构建它。扩展是无需编译即可加载、支持热重载的 TypeScript 文件，因此智能体可以"写代码、重载、测试，循环往复，直到扩展真正可用" [12][18]。OpenCode 的插件和自定义工具提供了类似的路径 [32]。开发环境早已可以定制，但定制过去需要耗费开发者自己的时间。当智能体来写定制时，每个开发者或每个项目都能拥有精确契合其工作流的工具。

7.6 与模型供应商解耦

三个工具都把开发工作流与任何单一模型提供商分开。OpenCode 可连接 75 家以上的提供商，包括本地模型 [24]。Pi 的 pi-ai 包在一个 API 下支持 31 家 API key 提供商及云平台 [21]。Orca 更进一步，把整个智能体视为可互换的。它托管 31 个具名 CLI 智能体，并跟踪其中若干的速率限制 [1][8]。因此，模型选择成为按任务基于成本、速度或质量做出的运营决策，而不是平台承诺。它也降低了某一家供应商定价或政策变动导致团队工作中断的风险。

7.7 新的安全与治理职责

运行 shell 命令的智能体把提示注入和供应链攻击变成了现实风险。Pi 的文档直言不讳：它"不会在每次工具调用前请求批准"，文件和命令输出可以通过提示注入操纵模型，而且"观看记录、使用项目信任、审查改动都无法构成安全边界" [22]。OpenCode 提供 allow、ask 和 deny 规则，但默认在无批准的情况下启用所有工具 [28][29]。Orca 的 worktree 把智能体的文件彼此隔离，但并不把它们与宿主系统隔离 [5]。

因此，采用这些工具的团队要承担新的职责：选择沙箱或容器、编写权限策略、审查第三方扩展与插件，并把智能体输出视为不可信输入。Pi 自身的供应链实践——如固定依赖、延迟采用依赖以及带 shrinkwrap 的发布 [9]——展示了智能体密集型开发所要求的纪律。信任依然有限：在 2025 年 Stack Overflow 调查中，46% 的开发者不信任 AI 输出的准确性，33% 的开发者信任 [42]。

7.8 综合

总体而言，证据表明这些工具更可靠地改变的是开发者精力的去向，而非减少所需的精力。精力从敲代码转向描述任务、策展上下文、监管并行尝试、评审 diff 和管理风险。这是否带来净收益，取决于任务类型、代码库成熟度以及周边工程实践的质量 [39][43]。三个工具代表了三种让新工作高效化的押注：OpenCode 押注内置能力，Pi 押注透明与自我扩展，Orca 押注并行与评审。

8、讨论与局限

分层，而非竞争。 Orca 是监管者而非智能体，它的价值随着 OpenCode 和 Pi 这类智能体的进步而增长。主要的设计对比在两个智能体之间：丰富的内置能力，对比极简、可检查的核心。两种路径在某些领域可能会趋同。Pi 用户可以通过扩展添加计划模式和权限门，OpenCode 用户则可以限制工具并依赖外部沙箱。

治理。 三个项目都是 MIT 许可，但各自都有一家公司作为管家：Stably AI、Earendil 和 Anomaly。Zechner 关于 Pi 核心保持 MIT 的公开承诺 [13] 是一种意向声明，而非对未来代码的法律保障。持续的开放开发取决于这些公司的商业模式。

局限。 第一，这些项目几乎每天都在发布，功能和指标会很快过时。第二，我们没有运行基准测试，也没有任何一手资料报告覆盖三个工具的可比任务成功率数字。第三，star、下载量和自报用户数衡量的是关注度和分发，而非质量或生产力。第四，大多数功能描述来自项目自身的文档，未经独立测试。第五，第 7 节引用的生产力研究评估的是其他工具（GitHub Copilot 和 2025 年初的前沿 AI 工具），因此不应把它们的结果读作对这三个工具的测量。

开放研究问题。 需要对照研究来考察：(a) 并行多智能体工作流是改善了结果，还是仅仅转移了评审负担；(b) 极简与丰富的智能体-计算机接口在同一模型和任务上如何比较；(c) AGENTS.md 和技能如何影响智能体的成功率；(d) 哪种权限与沙箱默认设置能在安全与开发者摩擦之间取得平衡。

9、结束语

Orca、Pi 和 OpenCode 是 AI 编程栈中三个开源、MIT 许可的层次。OpenCode 按 GitHub star 数（209,481）采用最广，并提供最丰富的内置功能集：五个智能体、13 个工具、34 个内置语言服务器、一个权限系统以及有文档的服务器 API。Pi 表明，一个四工具、可自我扩展、采用树状会话的核心也能达到可比的分发量（30 天内 937 万次 npm 下载）。Orca 创建于 2026 年 3 月，它增加了一个基于 worktree 的编排层，让单个开发者同时运行和评审多个智能体。

这些工具通过把开发者的精力从编写代码转向规格声明、上下文策展、并行监管、评审和风险管理来改变软件开发。关于净生产力的实证证据好坏参半，并取决于具体情境。未来工作应在共享基准上评估这些工具，并在真实团队中研究开发者如何在自己与被编排的智能体之间分配工作。

原文链接: Orca, Pi, and OpenCode: Open-Source Agentic Tools and the Changing Practice of Software Development

汇智网翻译整理，转载请标明出处