体验过不同风格的 AI Coding 工具后你是否曾想过拥有自己的 Coding Agent特别在企业软件领域复杂的业务上下文、工程环境与集成需求使得定制专属的 AI Coding 平台可能成为一项更具价值的长期能力建设。而且这并不局限于编程。只要替换必要的技能和工具同一 Agent 系统就能延伸到客服、运维、办公等更多业务场景。而定制的最佳方式是基于一个强大的 Harness 底座做扩展。本文将基于最近较热的三个开源 HarnessPi、DeepSeek Harness、Codex Harness深入了解它们的架构、扩展能力以及选型策略。在后续文章中我们将逐一实战探索如何基于它们构建自己的 Agent 系统。为什么选择这三个 Harness我们当然可以使用大模型 API 或者 Google ADK 这样的框架手搓自己的 Agent。但一个更现实的选择是用开源且有着良好扩展能力的 Harness 做底座再把企业独特的部分接进去。比如构建一个企业专属的 Coding Agent你可以把企业内部系统的连接变成预置能力定制专属的上下文加载机制修改安全机制以符合企业的合规要求替换必要的底层基础设施比如文件系统从 Coding Agent 开始是因为文件、命令和代码差异都便于验证。但你完全可以把 read、write、bash 这些工具换成查客户、读工单、创建订单等再给予特定的知识Agent 的应用领域就变了。不同的 Agent 可以共享 Harness 基座的通用能力选择这三个开源 Harness 基座还因为它们同时满足一些条件源码开放且可检查具备会话、循环、工具使用与上下文等可复用的核心提供真正的扩展能力或接口而不只是修改提示词提供多样、灵活的交互与调用方式如 SDK、RPC 等后面我们将看到它们也代表三种完全不同的开放方式。Deep AgentsLangChain 公司与 OpenCode 也都是非常强大的开源 Harness。我们选择 Pi是因为它更轻量采用了“小内核、大扩展” 的设计。下面来认识这三种不同的 Harness并重点关注其定制与扩展能力。02Pi小内核、大扩展Pi 是一个多层开源框架这里我们关注最上层的 Pi-Coding-Agent。在交互与集成方式上它提供了一个开箱即用的 TUI 编程 Agent但同时提供 RPC、SDK 等更灵活的调用方式。所以即使你不对它的能力扩展也可以很方便的把 Pi-Coding-Agent 集成到你的应用中。比如你可以在 Web 应用中使用 SDK 调用 Pi 来实现智能体能力也可以利用 Pi 的 RPC 调用方式开发自己的 VS Code 插件。在扩展能力上Pi-Coding-Agent 的核心思想是它把通用的 Agent Core 做好再通过集中的ExtensionAPI开放工具、命令、事件、模型和 TUI 组件等全面的扩展能力。Pi-Coding-Agent 的整体架构看图默认的 Pi-Coding-Agent 采用了一种克制到近乎“吝啬”的策略 — 没有 MCP、没有 Subagent、没有 Plan Mode、没有 Todo 工具也只有可怜的 read、write 少数几个。简单说就是我负责把最核心的引擎做好剩下的你们自己写扩展吧。正因为如此Pi 提供了极强的扩展能力 — 不仅仅是增加 Tool能力扩展改变与增强 Agent 的基础能力工具、上下文、事件等交互扩展改变用户与 Agent 的操作方式比如斜杠命令、快捷键界面扩展改变 Agent 长啥样TUI比如状态栏、对话框等借助这些扩展的“组合”你可以轻易获得私人定制的 Agent — 用 TS 开发然后打包放到扩展目录... exportdefaultfunction(pi: ExtensionAPI){ pi.registerTool(queryCustomer); //扩展toolpi.on(tool_call, auditBeforeCall); //扩展事件钩子pi.setActiveTools(activeTools); //控制工具启用pi.registerCommand(planCommand); //扩展命令pi.registerFlag(sandboxFlag); //扩展启动参数 }...如果你不喜欢 Pi 默认的“毛坯” TUI也可以借助 TUI SDK 来个性化。比如我就给它加上了自定义的侧边栏如果需要扩展到更通用的企业 Agent 你无需关心怎么写 Agent Loop 和管理 Context只需要借助 ExtensionAPI 改变系统提示、换一套企业能力 Tools、告诉 Agent 如何加载领域知识然后开发你的UI 并使用 RPC/SDK 调用你定制的 Agent。03DeepSeek Harness不是扩展、而是组装 Agent下面来到我们的国产之光DeepSeek Harness以下简称 DSH。在交互与集成方式上与 Pi 类似DSH 默认提供 WebUI但同时可通过 SDK、Web/API、ACP 交互调用方便与其他应用集成。而在扩展能力上DSH 采用了一种极端的设计思想Everything is a Plugin。它的中心是 Cordis 插件系统。模型适配、工具注册表、会话日志、文件系统、Shell、Sandbox 等都是插件最重要的是核心的 Agent Loop 也是插件。而Cordis 内核主要负责装载、卸载、依赖等管理。DSH 的扩展架构用下图来理解注意 Agent Loop 也是插件换句话说DSH 的扩展理念是我提供模块管理能力所有模块你都可以自己建造和更换包括核心引擎。因此DSH 插件与 Pi 扩展的最大区别是Pi 的 Extension 扩展的是 Pi-Coding-Agent 外围而 DSH 的插件则是共同构成了 Agent 系统本身。那么 Cordis 到底是什么简单说Cordis 是 DSH 的插件运行与管理系统。它本身不负责思考而是负责把各类插件组织成一个完整的 Agent。职责包括通过ctx共享能力例如ctx.tools、ctx.llm根据依赖关系启动插件管理插件的加载、卸载和清理打个比方Cordis 就像一块乐高底板模型、工具、Agent Loop 都是积木ctx是它们间的统一接口Cordis 负责按照依赖把它们装好也能随时拆下或替换。看一个在 DSH 中扩展 Tool 的例子importtype{ Context }fromdeepseek-ai/cordisimport{ defineTool }fromdeepseek-ai/dsh-toolsexportconstname tool-helloexportconstinject [tools]exportfunctionapply(ctx: Context){ ctx.tools.register(defineTool({ name:hello, description:向指定的人问好, parameters: ..., output: ...,asyncexecute({ name }) {...}, })) }开发似乎和 Pi 很像通过 register 注册自己的 Tool然后将插件包安装到 DSH 并做相关配置即可。但这里的关键不是 register而是 inject[tools]它代表你注册的 hello 工具依赖于 tools 这个注册服务只有这个服务可用hello 工具才激活。这是一种 Cordis 管理插件依赖关系的方法所以 tools 这个工具注册服务本身也是插件 — 万物皆插件。在 DSH 中插件的使用还有一个重要的机制 — “接缝”我们将在后续文章中做深入讲解。通过不断开发 Plugin理论上你可以近乎无限的组装出适合自己或企业的各类 Agent 社区里已经涌现出大量 DSH 的插件。04Codex稳定内核按标准扩展能力OpenAI 也正式开源了 Codex Harness最近的 O 社比 A 社要良心多了这让我们可以充分利用其优秀的 Harness 来驱动自己的 Agent 系统基于 Codex Harness 构建的 Agent DemoCodex 开源的是一套以 Rust 实现的成熟 Harness 内核这与 Pi-Coding-Agent 类似内核已经帮你处理了 Agent Loop、流式事件、上下文管理、工具编排、会话恢复以及沙箱、权限和审批等复杂问题。Codex Harness 的架构在交互与集成方式上Codex 也提供多种方式Codex exec适合脚本、CI 和一次性任务可以对应 Pi 的 TUICodex SDK适合在程序中启动和恢复任务对应 Pi 的 SDK 调用App Server适合深度嵌入 GUI、IDE 或企业系统对应 Pi 的RPC 调用两者都是 stdio 通信但 Codex App Server 提供了更完整的能力在扩展设计上Codex 没有提供一个类似 PiExtensionAPI的深度定制入口更多是基于现有标准的扩展方式。包括AGENTS.md注入你的项目规则、领域知识和顶级约束Skills封装可复用的 SOP、知识和脚本Hooks在工具调用、会话结束等节点执行自定义逻辑MCP接入企业数据、工具和业务操作Plugin把 Skills、MCP 和 Hooks 打包成可分发安装的能力包当然如果这些都不“过瘾”你还可以直接修改 Rust 内核 — 自由度最高但维护成本最高。所以Codex Harness 的扩展思想是保留稳定的、企业级 Harness 内核再基于 MCP 等标准机制扩展自定义指令、流程、工具等并通过开放接口嵌入到你自己的应用。从扩展能力来说Codex Harness 没有 Pi 和 DSH 那么自由和开放其优势在于一个强大的 Agent Core 和扩展的简洁性。05三条扩展路线应该如何选择现在我们可以对三个 Harness 的架构与扩展能力做一个综合对比或者简单的记住这张图再或者记住这三句话Pi 擅长深度改装出一个 Agent但内核还是人家的DSH 擅长用插件组装一个全新的 Agent 系统包括内核Codex 擅长在成熟 Harness 外围扩展新能力并为我所用一个是改装现有工厂一个是组装模块化工厂一个是给成熟工厂接入新能力。三者也都能通过 SDK、RPC 等方式集成进现有企业应用。【企业或团队如何选择与落地】Pi适合希望先有一个完整 Agent再围绕它定制开发增加能力的团队个人或小团队编程场景喜欢用 TUI需求集中在工具、命令、事件的高度定制想拥有自己的 TUI特别看重框架的简洁性以及深度扩展能力典型应用团队专用 Coding TUI 或 VS Code 插件、深度定制专用 AgentDSH适合希望建设高度自主、可插拔能力的企业级 Agent 平台的团队对 Agent 的所有部件都希望能高度灵活的定制包括 Agent Loop希望用插件组合出不同类型的 Agent用于不同的场景同一能力需要在本地、容器、云端和企业内网中切换多种实现典型应用企业内团队协作的统一 Coding 平台、多运行环境的 Agent 系统Codex适合希望用尽量少的开发把企业知识、工具和流程快速沉淀为标准化能力并在多个 Agent 场景中复用的团队希望用最少量的开发接入一个稳定的 Agent Harness希望通过 MCP、Hooks、Skills 等标准接入企业系统、知识与流程重视沙箱、审批、权限与扩展信任等企业治理能力典型项目需要统一分发工具和技能等能力的企业 Agent 平台、办公 Agent想深度定制改造得到一个自己趁手的 Agent选择 Pi想按模块重新组装不同的 Agent可以评估 DSH想把企业能力快速接入 Agent 并持续复用考虑 Codex在实际应用中企业也不必强迫所有场景只选一个 Harness 基座 。比如开发人员的编程场景用 Pi 或者 DSH而办公场景则通过 MCP 等扩展使用 Codex Harness而更复杂的业务场景你可能会使用 LangGraph 定制 Workflow甚至将多个 Agent 编排成 Graph 协同工作。总之选择开源 Harness 不是简单的挑一个“最好”而是在衡量业务需要、团队能力、开发速度等之后找到最适合自己的起点。