转载：小红书 AI产品赵哥
前言🔖
最近半年在帮几支做软件研发和企业级平台的团队看 Coding Agent 的架构。看得越多越觉得有意思：坑是同一个，连形状都长得都一毛一样！
原型阶段，模型只会聊天不够，得能改代码，加文件读写。改完跑不了测试，加终端执行。嫌它干活莽撞，加 Plan Mode 和 Todo List。大项目单线程跑不动，塞 SubAgent 和一堆 MCP 插件。再往后权限审批弹窗、长期记忆、后台异步任务。
单看每一项都合理，有的甚至不做不行。十几项叠进一个系统，事情就出问题了。
上下文先撑不住。每次对话底层都带着几万 Token 的工具定义和状态说明。执行路径也拉长了，改一行配置得先进计划模式列提纲，再派生两个 SubAgent 查环境。终端狂滚日志、甚至循环报错的时候，坐在屏幕前的人答不上来一个最简单的问题：它现在到底想干什么。
就在各家被自家 Agent 折腾得没脾气的时候，冒出两个方向相反的项目。Pi 走克制路线，DeepSeek Harness（后面简称 DSH）走深度模块化和动态组合。
一、事发现场：一个臃肿的 Agent 是如何把研发团队逼疯的？🔖
上个月在北京，一家做金融数据中台的团队。花三个月搓了套全功能研发 Agent，本意是自动修线上常规数据脚本的 Bug。架构师图一步到位，接了 12 个内部系统的 MCP（查库、看日志、拉代码、发飞书通知），内置严格的 Plan Mode 状态机，还设计了主 – 从 SubAgent 调度。
上线第一周，值班工程师就懵了：
一个数据清洗的 Python 脚本因为字段名变更报错。两分钟的活儿：打开文件，换掉旧字段，跑一遍测试。Agent 接手以后，初始化先把 12 个 MCP 的几十个工具 Schema 全塞进系统提示词，没动手就吃掉近 18000 个 Token。接着被状态机推进 Plan Mode，列了 8 步修复计划，其中一步是查三个月前的数据库变更记录。执行到第二步，主 Agent 唤起代码检索 SubAgent，后台同时起了个异步 Bash 拉测试环境日志。
Bash 卡在权限弹窗等人点确认。前台那个 SubAgent 不知道，看见日志是空的，判断环境没起来，转手调另一个 MCP 工具把代码库回滚了。等工程师强行掐断，代码已经乱了，屏幕上混着主 Agent、SubAgent、MCP 服务端和状态机切换的几千行输出。没人说得清它从哪一步开始跑偏。
负责人当时的原话我记着：本来想造个全能数字员工，结果造了个连自己都看不懂的黑盒。
问题不在某个组件写坏了。是这些功能全在默认主流程里，谁也绕不开。
二、Pi：想进核心，先拿证据 🔖
Pi 的做法有点不留情面。默认只给模型四个工具：read（读）、write（写）、edit（局部编辑）、bash（跑终端命令），over！
项目说明里写得很直白：MCP、SubAgent、Plan Mode、权限弹窗、内置 Todo、后台异步 Bash，一律不进默认核心。要高级能力，自己用 TypeScript Extensions、Skills、Prompt Templates 或者第三方包加。
第一眼像功能没做完。但设计者算过一笔账。任何能力一旦写进核心，系统就得长期背三样东西。
- a. 上下文成本：模型必须理解更多工具定义、状态和规则；
- b. 决策成本：Agent 多出新的行动路径，也多出新的误用方式；
- c. 维护成本：开发者需要处理兼容性、权限边界与异常状态。
所以 Pi 把举证责任倒过来了。一项能力不能因为 “可能用得上” 就进核心，得先证明收益明显大过这三笔成本，否则免谈。
它也因此不急着发明 Agent 专属的抽象。文件系统、命令行、进程，人类用了几十年，够用了。要计划？让 Agent 用 write 把计划写进项目根目录的 plan.md，做完一步用 edit 打个勾，人随时能翻开看。要多 Agent 协同？bash 起独立进程，靠标准输入输出或临时文件通信，挂了直接 kill。要权限隔离？整个 Pi 丢进配好边界的 Docker 或虚拟机，用操作系统自己的权限锁死，比在应用层写审批弹窗牢靠。
杭州有个八人小团队，专帮出海电商客户重构老 PHP 系统。早先也用大而全的框架，后来全推了。现在跑任务很朴素：每次启动先 read 本地 progress.log，bash 跑单测看哪儿红，edit 改，改完再跑，过了就把结果追加写回日志。没有记忆插件，没有规划模块。
好处很实在：终端和文件夹打开就是全部现场，出了事边界一眼能划清。个人工具、中小项目里，少一层自己发明的状态机，往往就少一大类复现不了的怪问题。
💡 Pi 的赌注是：缺的功能随时能补，复杂度一旦进了核心，想再拿掉就难了。
三、DSH：复杂度赶不走，那就让它可撤销🔖
在几百人的研发部门管过跨团队 AI 基础设施，很快会撞上 Pi 路线的软肋。DSH 就是从这儿起步的。
它的前提挺冷静：企业确实需要多模型切换、细粒度权限、跨天会话、并行多 Agent、动态挂接业务工具。核心不收，这些复杂度不会消失。
既然总量守恒，问题就换了：怎么给复杂度划出清楚的边界。
DSH 底层是 Cordis，一个强调依赖注入和上下文隔离的微内核框架。里面几乎没什么是固定在主板上的。模型适配器、工具注册表、会话日志，连最核心的 Agent Loop 都是插件拼出来的。架构文档里反复讲一个词：能力的注册，本质上是可卸载的副作用。插件装上卸下，系统能力跟着实时变。Agent 核心接口刻意不绑死某一种循环实现，SubAgent 这种重家伙也放在外面，由独立 Provider 提供。
真正关键的是可逆组合。
大而全的工具为什么容易烂尾？某项能力写进主流程，别的模块不知不觉就对它产生隐式依赖。半年后想删，一删编译就报错，牵一发而动全身，谁都不敢动。DSH 的办法是硬约束：模型、工具、沙箱、会话状态、调度循环之间只走明确定义的标准接口。能干净地加，也能干净地退，不留残渣。目标不是一个永远庞大的巨型 Agent，是让形态随任务实时重组。
一个 Agent 塞三种需求，出来准是精神分裂。分三套从头开发，模型调用、日志监控、报错重试又得写三遍。DSH 下是同一个底座： 早上跑审查，卸掉网络和 SubAgent 插件、挂只读沙箱；下午跑研究，装上并行调度 Provider 和搜索工具集。形态变了，底座没动。
四、差别在控制权什么时候交出去🔖
Pi 与 DSH 最深的差异，落在控制权进入系统的时点。
- Pi 更信任设计时的显式选择。开发者编写扩展、安装包、启动进程并决定隔离方式；Agent 在这套边界内完成任务。即使 Agent 可以帮助生成扩展代码，能力是否进入运行环境，通常仍然经过用户可见的安装或加载过程。
- DSH 则试图让一部分配置权进入运行时。官方的
tool-cordis扩展允许 Agent 检查当前 Cordis 运行环境，在沙箱中定义工具或服务，并临时挂载到当前进程。官方文档也明确写出了现阶段的边界：这些定义只存在于进程内，DSH 重启后会消失，也不会自动写入项目配置。
这一能力很容易被描述为 “自我进化”，但更准确的名称应当是运行时自我改装。
进化意味着经验能够跨任务保留，失败会影响下一轮选择，有用能力经过验证后能够稳定沉淀。当前的临时插件主要完成了其中第一步：发现缺口后生成并挂载新能力。它尚未自动解决版本管理、长期持久化、回归测试、权限审计和能力淘汰。
换句话说，DSH 打开了一扇门，但门后的治理制度仍在建设。
五、极简与模块化并不互相替代🔖
- Pi 最强的反对意见是：很多所谓模块化系统，只是把一个复杂核心拆成许多复杂包。插件数量增加后，依赖顺序、版本冲突、隐式事件和生命周期管理依然可能形成新的 “分布式核心”。此时，架构图虽然漂亮，理解系统的成本却没有真正下降。
- DSH 对 Pi 的反驳同样有力：外围复杂度也是真实复杂度。把 Subagent、审批与调度交给脚本，不会让它们消失，只会让它们缺少统一接口、状态记录和生命周期管理。当系统走向多人协作、长期运行和多种 Agent 共存时，极简核心可能把维护成本转移给每一个集成者。
因此，两条路线各有适用范围：
- Pi 更适合能力边界稳定、开发者深度参与、可观察性优先的场景 —— 优化的是 “单个 Agent 如何保持清醒”；
- DSH 更适合能力组合频繁变化、多个运行环境并存、需要统一治理的系统 —— 优化的是 “许多不同 Agent 如何共享一套基础设施”；
六、真要放开自扩展，缺的是一部宪法🔖
往后看两三年，DSH 这条可逆模块化加运行时自改装的路，商业想象空间确实更大。风险也更大，而且容易被 “自进化” 这种好听的词盖住。
顺着 tool-cordis 再想一步。企业真允许 Agent 运行时自己写代码造工具、改运行环境，甚至把好用的临时工具沉淀下来，新能力的增长速度会远快过工程师开发和审查的速度。能力涨得快，安全攻击面、内部状态组合、故障连锁的可能组合同样按指数涨。
生产环境里，一个有权改自己运行环境的 Agent 要上岗，架构师得逼着系统把四个问题答成制度加代码，不能只是写在文档里。
- 资源边界：新造的能力能碰哪些底层资源？能不能偷读宿主机环境变量，能不能随便往公网发请求？
- 结果验证：它说造了个工具解决了卡点，谁独立复核？怎么防它篡改测试标准或者吞掉异常来糊弄系统？
- 故障回滚：挂上去五分钟后内存泄漏、数据污染，能不能一秒内连根拔起，把受影响的外部状态退回挂载前那一刻？
- 转正晋升：每天几百个临时能力，哪些够格从用完即焚变成写进配置的正式能力，考核指标是什么？
这四条没落成硬约束就放开自扩展，精妙的插件系统不出一个月就会变成全自动生产技术债的垃圾场。为眼前一次局部报错随手搓个粗糙工具挂上，表面糊过去了，却给未来埋了一条人很难察觉的隐式依赖。攒久了满系统都是 AI 自己写的、没文档没规范的补丁，直到某天整体崩掉，最厉害的架构师也拆不动。
所以 DSH 这类系统下一阶段该盯的指标，不该是 Agent 运行时又造出多少花哨工具。反过来：一个新能力能不能走完沙箱隔离试验、权限最小化收缩、自动化回归验证、真实业务效果评估、人工确认审批，才准进持久化配置。