AIPHarness 与 DeepSeekHarness 的深度对比
软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。
都叫 Agent 框架，其实完全不是一类东西，我们AIP技术团队研发的Harness跟DSH的对比分析，主要是AI做的分析报告。
如果你正在挑一个"AI 智能体框架"，大概率会遇到一个尴尬：两个项目名字里都有 harness，都号称"企业级 Agent 平台"，文档里都写着 ReAct、工具调用、RAG、MCP。但把它们放在一起看，你会发现它们几乎不重叠。
我拿两个真实项目做了逐层对比：
- AIPHarness ：Java / Spring 技术栈的企业级 Agent 中台，当前版本
2.2.0-SNAPSHOT； - DeepSeekHarness ：TypeScript / Node 技术栈的 Agent harness 内核，当前版本
0.1.0-rc.5（明确标注预发布）。
一个约 6.8 万行生产代码，一个约 25 万行。差近四倍，但代码量不是这篇对比的重点------重点是它们回答的是两个不同的问题：
AIPHarness 在回答："怎么把一个智能体交付给企业里的一千个业务用户用？"
DeepSeekHarness 在回答："一个智能体究竟应该被怎样组装出来？"
这两个问题都很值得回答。但拿回答 A 的产品去做 B 的事，会失败；反过来也一样。下面把分水岭一个一个拆开。
目录
- 第一个分水岭：不换代码，能不能换掉它的运行方式
- 第二个分水岭：AI"记得"的东西存在哪里
- 第三个分水岭：它能碰什么东西
- 四件两边都做了、但取向相反的事
- 成熟度不看代码量，看门禁
- 能力地图：一张表看完差异
- 场景对号入座
- 两个"不要"
- 能从对方身上抄走什么
第一个分水岭：不换代码，能不能换掉它的运行方式
这是最底层、也最容易被低估的差异。
DeepSeekHarness：一切都是插件
它的底座是一个插件框架，规则很硬：
- 没有特权内核。模型适配器、工具注册表、会话记录，甚至"智能体的主循环本身"都是插件。主循环在配置里就是一个可以被整行换掉的条目。
- 注册是带回收的副作用。每个能力注册时都会拿到一个"注销"句柄，插件卸载时它贡献的东西全部回卷。所以可以做到运行期热插拔，以及"每个子智能体看到不同的工具集"。
- 组合是分层的。一份基础配置，叠加安装包配置，叠加项目级覆写，叠加用户主目录覆写，叠加命令行临时覆写，按顺序压进去。任何一行都能被下面某一层的配置改掉。
它还有一条规范：一个能力扩展必须由三个角色组成------能力契约、能力实现、能力使用者 ，缺一个不算完整。看上去像官僚规定，但这是两百多个包能保持同一种形状的原因：本地文件系统和远程沙箱文件系统、本机 Shell 和容器 Shell、进程内子智能体和外部 Claude Code 子智能体，都是同一个契约的不同实现，可以互换。
实际效果：换掉推理模型、换掉沙箱后端、换掉子智能体实现，都是改配置，不是改代码。
AIPHarness：编译期装配
它是标准的分层架构 + Spring 依赖注入。想加一个工具，就写一个带注解的类，启动时被扫描注册------这条路很好走，而且它在启动时会对所有注解工具做一次自检，产出不了可用 schema 就直接让启动失败（这个设计值得称赞，它把"配置错误"挡在了运行之前）。
但底座是可替换性另一回事：大模型客户端、会话存储、工具执行器都是具体类的直接注入；模块之间能不能依赖，在 Maven 依赖图里就定死了。项目代码里甚至留着一处注释，说明因为某个依赖方向不允许，引擎只能绕过类型系统去读一个原始配置键------这就是编译期装配的税。
实际效果：换掉推理模型 = 改代码 + 重新编译 + 重新发布。
这条差异什么时候真的重要
如果你的框架只在一种场景用，上面这些是过度设计。但只要你需要下列任何一条，插件化就是必需品：
- 同一个智能体内核，既要在命令行跑，也要在 Web、在外部 IDE、在 Python 脚本里跑；
- 同一套业务逻辑，演示时用本地沙箱，生产换成容器隔离，不想改任何一行业务代码；
- 想验证"换个决策循环逻辑会不会更好"，而又不想污染主干。
第二个分水岭：AI"记得"的东西存在哪里
这是本次对比里差距最大的一项，而且它决定了后面一堆事情。
先解释一下术语。所谓模型上下文，就是"这一次请求里，模型实际看到的全部内容"------系统提示词、历史对话、历次工具调用的结果。它和"用户界面上显示的历史记录"是两回事：前者决定 AI 的行为，后者只是给人看的。
AIPHarness：上下文活在内存里
AIPHarness 的会话历史存放在服务进程的内存里，按任务编号索引。数据库里确实有一张事件流表，每个任务的过程事件按序号落盘，注释写着"按序号升序回放即可还原完整事件流"。
但它有两条无法回避的边界：
一、这条事件流是给前端回放用的，不是给模型用的。 把事件流还原成对话记录的那条路径只被网页推送层调用了一次。而"重新构造出模型该看的消息列表"这件事，整个代码库里没有一处实现。换句话说：两份状态不同源。用户看到的对话记录是完整的，模型看到的记忆不一定。
二、这条事件流是有意设计成"允许丢"的。 这里必须替它说句公道话------它的事件落盘治理做得相当成熟：
| 策略 | 做法 |
|---|---|
| 直接不落盘 | 计划逐字流、子智能体逐字流------内容已由终态事件携带，重复存没意义 |
| 节流合并 | 打字机式的增量帧只在内存保留最新一帧，靠三个时机冲刷落盘，把"每帧一行"压成"每次突发 1~2 行" |
| 有界队列 | 队列满时丢弃并计数告警，避免积压撑爆内存 |
| 加载上限 | 回放单次最多取固定行数，超出保留最新的，久远的被截断 |
| 失败降级 | 所有读写异常静默处理，保证持久化失败不影响实时推送 |
这套设计在"给前端看历史记录"这个目标下是完全正确的：宁可少几行，也不能拖慢主流程。
但正因为它是"宁可丢"的，它就永远不能充当模型记忆的重建依据。 这不是 bug，是它自己写明的取舍。
于是有一连串后果：
- 服务重启 / 发布，正在进行的对话上下文消失。
- 节点崩溃或被系统杀掉，任务会被后台清理器标成"中断"，用户能看到已经落盘的部分，但 AI 的那份记忆没了。
- 多实例部署必须"回到当初那个节点"。为此它实现了一整套机制：任务归属节点盖章、节点心跳保活、跨节点命令转发、跨节点消息流桥接、集群配额------粗算约一千二百行。这近千行代码存在的根本原因，就是那份内存状态搬不走。
- 同类内存态还有中断标志、工具上下文、确认账本、计划状态、用量面板......受同一条约束。
DeepSeekHarness：会话日志是唯一事实源
DeepSeekHarness 的做法是：先写日志，再从这里投影出模型该看的消息列表。 分叉、续接、转写、遥测，全都从这一条流派生。
它有一条被当成运行时不变量来执行的规则：
凡是进入模型请求的内容，必须可以从会话日志重建出来。 新增一类模型可见输入，就必须新增一种日志事件。
这条规则有个反直觉但极其重要的配套设计：日志不完整时，读取会直接失败。 它的已知事件类型清单（四十多项，而且是由代码自动生成、有门禁校验保鲜 的，不担心文档漂移）之外的任何事件，只要没带"可忽略"标记，整个日志就拒绝解释。理由是：静默跳过一条必需事件，会重建出一个错误的会话------而错误的会话比读不出来的会话危险得多。
两种取向其实都自洽：
- AIPHarness 把"不完整"吸收为降级（保可用性）；
- DeepSeekHarness 把"不完整"暴露为失败（保正确性）。
但它们不能混着用。一份允许丢的流，做不了记忆的事实源。 如果 AIPHarness 想补上这块，第一步不是加"从日志重建对话"的函数，而是先把事件流从"尽力而为"改成"保序不丢"。
DeepSeekHarness 由此白拿的能力：会话分叉 （从日志任意边界复制出一条子会话，子智能体直接建在这上面）、跨会话检索 （智能体可以主动查自己历史上干过什么）、逐文件 100% 的可重放回归。
第三个分水岭：它能碰什么东西
这一条决定了它们分别适合什么活儿。
AIPHarness 的手：伸向企业系统
| 方向 | 有什么 |
|---|---|
| 外部系统连接器 | 7 类 ：SSH 服务器、MySQL、PostgreSQL、邮箱、GitLab、Kubernetes、S3 协议对象存储；共 19 个模型可调用工具 |
| 知识库 | 完整一套：7 类文档解析、分段、索引队列与调度、成员权限（全文检索，不是向量检索） |
| 数据文件 | 拉取云端附件、剖析结构化文件、发布文件产物给用户下载 |
| 计算 | 远程容器沙箱执行 Python |
| 业务界面 | 内嵌浏览器、页面跳转、产物卡片、环境准备进度 |
| 平台层 | 多租户组织隔离、组织级并发配额、积分计费与支付订单、对象存储、管理台 |
连接器这块有个细节值得点名表扬：读写动词的白名单是写在适配器内部的，不是只写在提示词里。比如 GitLab 工具只放行 GET，K8s 只放行 GET，对象存储只放行 GET/HEAD------越界直接抛异常拒绝。所有写操作被标为高危、需要用户确认。把约束落在代码层而不是措辞层，这是正确的位置。
DeepSeekHarness 的手：伸向工程环境
| 方向 | 有什么 |
|---|---|
| 文件系统 | 宿主工作区的读、写、精确编辑、结构化编辑、glob、grep，且有"写之前必须先读过"的策略约束 |
| Shell | bash 与 PowerShell，本地和沙箱两种后端 |
| 持久终端 | 打开一个长期存活的交互终端，能读屏幕、发按键、发信号 |
| 进程管理 | 进程树级管控，统一的任务列表 / 取输出 / 杀任务 |
| 代码智能 | LSP 集成：跳定义、找引用、实现、悬停 |
| 沙箱 | 操作系统级约束：Linux 命名空间与 Landlock、macOS Seatbelt、Windows ACL。沙箱不可用时直接拒绝执行，不会退回"裸跑" |
| 编排 | 并行子智能体（8 种后端共用一个契约）、工作流脚本、代码模式 |
| 协议 | ACP、JSON-RPC、Typert RPC、TypeScript 与 Python SDK |
注意一个容易看错的地方：DeepSeekHarness 的沙箱和 AIPHarness 的沙箱不是一个东西。 前者是"限制一个本地进程能碰哪些文件和目录"，后者是"把代码丢到远端容器里跑"。前者适合代你在自己机器上干活，后者适合让不可信的用户代码离你的服务器远一点。
所以真正的差别是
一个很能说明问题的数字：两边工具数量相当，但构成完全相反。
- AIPHarness 的五十多个工具里，约 23 个是向外伸的 （19 个连企业系统 + 4 个查知识库），约 26 个是平台自身能力（沙箱文件与代码执行、记忆、人格、技能、定时、图像理解、时间工具）；
- DeepSeekHarness 的五十多个工具几乎全部落在工程环境与自己这台机器上（文件、编辑、Shell、终端、任务、LSP、子智能体、工作流、代码模式）。
换句话说：一个把工具当作"接入企业系统的接口"，一个把工具当作"操作工程环境的手"。 这不是实现水平的差距，是任务形态的差距：写代码的智能体必须能碰到真实的仓库和终端；处理业务的智能体必须能碰到真实的系统和审批流。
四件两边都做了、但取向相反的事
这一节最有意思，因为双方在这里互有胜负，而且各自的解法都值得对方抄。
4.1 工具太多，撑爆上下文怎么办
两边都有五十多个工具，数量上其实相当。
AIPHarness 的方案更进一步 ：把"工具目录"和"已激活工具"分成两级，给了模型三个元工具------浏览工具目录、加载工具（按分组或指名）、释放工具（归还上下文空间）。模型自己发现能力缺口，自己去加载。而且激活发生在工具执行阶段，下一轮请求自然带上，时序不需要额外编排。
DeepSeekHarness 的方案是静态裁剪：用智能体预设和工具过滤器决定这一路能看到什么，兜底靠上下文压缩。
在同等规模下，AIPHarness 这条路径 DeepSeekHarness 完全没有对应原语，值得反向吸收。
4.2 不可信内容怎么防
智能体最大的攻击面不是网络端口，是它读进来的内容里可能藏着指令（网页、文件、邮件、第三方系统返回值）。
AIPHarness 在这里领先，而且实现得完整 ：工具可以声明自己的输出是"外部信任级"（支持类级默认 + 单工具覆写），命中这个标记的结果会被包进一层带信任属性的结构、做边界伪造转义，并且展示给用户的文本和送给模型的文本是同一份（防止两边不一致被利用）。可疑特征命中时，还会落到一张安全留痕表------只留痕不拦截，把判断权交回人。
DeepSeekHarness 在这次核对的版本里没有等价机制。 它的信任边界在另一个层面：路径、符号链接、工作目录授权、审批策略。它防的是"这条命令能不能碰这个文件"，不防"这段返回内容是不是在骗模型"。
反过来，在文件与路径这一层，DeepSeekHarness 也是代码级 fence：先解析真实目录再做规范化、按进程实际到达的目录授权、写之前强制先读。而 AIPHarness 的文件约束更多依赖沙箱白名单和提示词里的规则。
一句话：一个防"内容"，一个防"路径与权限"，两份清单几乎不重叠。 这是最应该互抄的一段。
4.3 成本怎么算
方向完全相反，而且两边都有实打实的缺口。
| AIPHarness | DeepSeekHarness | |
|---|---|---|
| 有什么 | 账本：模型费率表（输入价 / 输出价 / 加价系数 / 元兑积分）、消费记录、支付订单、余额拦截 | 成本模型：每模型五档价格（输入 / 输出 / 缓存命中 / 缓存写入 / 合计）、可预测"下一次请求要花多少" |
| 缺什么 | 只有输入 / 输出两档，没有缓存分档 | 明确写着"这个值只是给用户看的参考，不作为计费或放行的输入"------不做账 |
| 亮点 | 消费时写入单价快照，改价不追溯历史账单（账务正确性做对了） | 上下文压缩有影子价格：被剪掉的内容按同一把尺子定价并留一条事件，让纯消费者不必自己记账就能扣减 |
对 AIPHarness 这类平台，两档计价是有真实后果的：不少模型对命中缓存的输入 token 单独定低价，如果账单一律按标准输入价扣，命中时多扣了用户的，未命中时平台少收了钱。补法很明确------费率表加缓存两档，取用量时读上游返回的缓存明细字段。（这条要看实际供应商的计费方式验证。）
对 DeepSeekHarness，它把成本建模做得比大多数商业平台都细，却拒绝把它变成账。这符合它的定位：它是内核，不是对外收费的产品。
4.4 并发：两边各强一半
| AIPHarness | DeepSeekHarness | |
|---|---|---|
| 任务之间 | ✅ 虚拟线程 + 全局配额 +每组织一份配额双层限流。注释还专门辨析过：限的不是线程数，是并发语义 | ○ 没有租户概念，单机进程 |
| 任务之内 | ✗ 一轮里的多个工具调用严格串行执行 | ✅ 工具可声明"这次调用并发安全"，安全才进并行组；判定不确定时一律退回串行（无声明、判定器抛异常、返回值不是明确的真、参数没通过校验------四种情况全部降级） |
还有一点很关键：DeepSeekHarness 有测试专门锁住"这个并发声明不会泄漏进发给模型的 schema"------发给模型的工具描述里只有名字、说明、参数三项，执行细节不可能被带出去。
所以结论是：AIPHarness 在任务间并发治理上更完整，DeepSeekHarness 在任务内并发治理上更完整。
成熟度不看代码量，看门禁
我原本准备把这一节写成"工程治理差距"，但核对之后要收敛：AIPHarness 的注释质量和职责边界纪律是真实存在的 （它有专门的类只保留框架自有分组名、明确禁止业务分组混进来，甚至记录了与内部另一个项目的刻意差异），它已有的测试质量也不低（有专门校验工具分组声明规范的测试）。差距不在意识，在有没有把它变成机器强制。
| AIPHarness | DeepSeekHarness | |
|---|---|---|
| 测试占代码 | 10.3% | 54.7%（约 39 倍） |
| 测试覆盖分布 | 5 个模块有测试，10 个模块为零------其中包含连接器和知识库 | 逐文件 100% 覆盖率门禁，豁免必须写进清单 |
| CI 流水线 | 4 个 GitHub workflow + Jenkins | 15 个 workflow，14 个门禁聚合（带依赖图与并发调度） |
| 静态检查 | 无 lint / 格式化 / 覆盖率 / 重复度门禁 | 类型检查、lint、跨文件克隆检测、未引用导出检查、发布规范检查、若干仓库专属校验 |
| 行为可复现性 | 依赖真机与外部模型 | 无密钥快照回放：任何非平凡的模型可见或用户可见行为变更，同一个 PR 必须带一个可回放的真实产物快照；用 mock 的包级测试不算数 |
| 决策记录 | 阶段性报告若干，且部分已过期失真 | 1372 篇结构化决策记录，分"已实现 / 提议 / 否决 / 归档"四态，归档即冻结；非平凡改动必须同 PR 带一篇 |
| 文档一致性 | README 与实际模块数不一致；能力矩阵把已上线的功能标为缺失 | 文档预算门禁 + 全站同步门禁 + 站点构建兼作死链检查；中英双语三件套 |
"测试覆盖率低"这件事本身不致命，致命的是它分布得没道理：连接器（拿着企业凭据、能干写操作）和知识库（内容会进入模型上下文）这两个最需要围栏的地方，恰好零测试。
这不是"没时间写测试"，是风险排序没做。
能力地图：一张表看完差异
● 完整 / ◐ 部分 / ○ 无
| 能力 | AIPHarness | DeepSeekHarness |
|---|---|---|
| ReAct 主循环 | ● | ● |
| 主循环可被整体替换 | ○ | ● |
| 多模型适配 | ◐ OpenAI 兼容为主 | ● 多协议按路由分发 |
| 模型重试与退避 | ● | ●（独立可换组件） |
| 上下文压缩 | ● LLM 摘要 + 分批 + 抽取式兜底 | ● 多个实现 + 压缩成本核算 |
| Token 用量计量 | ● 三档 | ● 五档（含缓存） |
| 计费 / 账务 | ● | ○（刻意不做） |
| 会话持久化 | ◐ 事件落库但模型记忆在内存 | ● 日志即事实源 |
| 会话分叉 / 回滚 | ○ | ● |
| 跨会话检索 | ◐ 知识库检索 | ● 可查自己历史行为 |
| 长期记忆 | ● 独立记忆库 | ◐ 靠指令与引用约定 |
| 人格 / 角色 | ● | ● |
| 技能体系 | ● 数据库管理 + 打包落沙箱 | ● 文件系统 + 加载工具 + 目录 |
| 子智能体 | ◐ 单一实现，迭代数硬编码 | ● 一个契约 + 七个可互换实现（进程内 / 分叉 / 外部协议 / 其他编码智能体） |
| 工作流编排 | ○ | ● 脚本级扇出与并行 |
| 后台任务 | ◐ | ● 统一托管 |
| 定时任务 | ● Quartz，cron 触发回灌 | ◐ 会话内提醒，自述只在会话存活时准点 |
| 计划模式 | ● | ● |
| 人工审批 / 交互 | ● | ● |
| 业务页面交互闭环 | ✅ 可挂起等待用户在页面上实际操作并回报 | ○ |
| 宿主工作区文件系统 | ○（仅沙箱内临时工作区） | ● |
| Shell | ◐ 仅远程 SSH | ● |
| 持久终端 / 进程管理 | ○ | ● |
| 语言服务（LSP） | ○ | ● |
| 沙箱隔离 | ● 远程容器，与宿主彻底分离 | ● 操作系统级进程约束 |
| MCP | ●双向（对外暴露 + 代理远端） | ◐ 仅客户端 |
| 知识库 / RAG | ● | ○ |
| 外部系统连接器 | ● 7 类 19 工具 | ○ |
| 多租户 / 组织隔离 | ● | ○ |
| 对象存储 / 产物发布 | ● | ○ |
| 管理台 | ● 八个视图域 | ◐ 前端是产品本身，不是管理台 |
| 可观测性 | ◐ | ● 含 OpenTelemetry 与运行时不变量诊断 |
| 协议化对外驱动 | ◐ REST / SSE / WebSocket | ● 多协议 + 多语言 SDK |
| 智能体改自己的运行时 | ○ | ✅ 可自举 |
| 外部编码工具生态兼容 | ◐ | ● 兼容两类主流工具的钩子协议 |
| 双语文档 | ○ | ● |
看这张表最有效的方式，不是数谁 ● 多，而是看 ○ 落在哪一侧：
- AIPHarness 的空格集中在"工程环境"和"内核可替换性"；
- DeepSeekHarness 的空格集中在"企业平台"整块。
两边缺的正好是对方的全部。
场景对号入座
| 你的诉求 | 该选 | 原因 |
|---|---|---|
| 跟企业业务系统结合，企业级场景结合的 | AIPHarness | 基于SpringBoot和管理级别权限整合 |
| 给公司内部业务人员做一个能查数据库、发工单、读邮件、跑报表的智能体 | AIPHarness | 连接器、密钥信封、审批留痕、组织隔离、管理台，这些是它的本体 |
| 做一个自动处理运营流程、需要人在页面上点一下确认的智能体 | AIPHarness | "打开业务页面 → 挂起等用户动手 → 回收结果继续"这个闭环，对方完全没有 |
| 做一个能读企业文档回答问题的知识助手 | AIPHarness | 现成的文档解析、分段、索引、权限一整套 |
| 要把智能体按量收费 / 做积分包 | AIPHarness | 账本、订单、余额拦截都是成品（但记得补缓存分档计价） |
| 做一个能改代码、跑测试、提 PR 的编程智能体 | DeepSeekHarness | 需要宿主工作区、shell、终端、LSP、进程管理------AIPHarness 一个都没有 |
| 并行派活给子智能体的复杂研究流程 | DeepSeekHarness | 一个子智能体契约 + 七种可换实现，叠加工作流脚本扇出与工具级并行 |
| 想让智能体自己写代码来批量调用工具，减少往返 | DeepSeekHarness | 代码模式：一段程序内部调用工具，子调用重入完整审批与防护链 |
| 智能体要在一台真实机器上干活 | DeepSeekHarness、AIPHarness | 操作系统级沙箱，且不可用时拒绝降级为裸跑 |
| 要能审计"AI 当时到底看到了什么" | DeepSeekHarness、AIPHarness | 模型可见即日志，且日志不完整就拒绝读取 |
| 要在 CLI、Web、外部 IDE、Python 里跑同一套内核 | DeepSeekHarness | 多协议 + 多语言 SDK，内核与外壳解耦 |
| 需要随时换掉模型供应商 / 沙箱后端而不改代码 | DeepSeekHarness | 一切皆插件，契约与实现分离 |
| 执行环境必须与业务服务器彻底隔离 | AIPHarness | 远程容器天然进程外；dsh 的沙箱与宿主共享内核 |
| Java 团队维护、要接现有企业中间件 | AIPHarness | 技术栈匹配本身就是硬约束 |
两个"不要"
不要把 AIPHarness 当编程智能体的底座。
它的文件工具只在远程沙箱的会话工作目录里生效，命令执行只有 SSH 连接器（面向远程服务器，且是高危需确认路径）。
它没有"本地代码库"这个概念，没有持久终端，没有语言服务。想让它在真实仓库里干活，等于从零补一整套工程工具------那时候你其实是在自己写一个 harness。
不要把 DeepSeekHarness 当企业 Agent 平台。
它没有租户隔离、没有计费、没有知识库、没有管理台、没有 MCP 服务端，而且按设计是单机本地优先的形态（跑在你机器上的一个进程，不是一套要横向扩的服务）。
它自己把话说明白了：预发布阶段，会有破坏性变更。
能从对方身上抄走什么
对企业级 Agent 平台（AIPHarness 这一类）
- 把护栏阈值变成配置。 同一份代码里，持久层的参数全是可配的，主循环的十个安全阈值却是硬编码常量。这不是能力问题，是没想到。
- 上下文成本模型至少补到"缓存"一档。 只有输入 / 输出两档的费率表，对按缓存命中分价的模型一定会算错账。
- 给一轮里的工具调用做并行，但默认关。 判定不确定时退回串行------这一条比"支持并行"本身更重要。
- 把事件类型清单变成生成物 + 让不完整的回放显式失败。 手写的枚举 + 静默跳过未知事件，迟早会变成"看起来正常但内容缺了一块"的转写。
给 Agent harness 内核（DeepSeekHarness 这一类）
- 外部内容信任标记。 工具声明自己的输出是不可信内容 → 统一包装 + 边界伪造转义 + 只留痕不拦截。这是防提示注入的一条真边界，而且实现成本低。
- 工具目录两级激活。 让模型自己浏览、按需加载、用完后释放。五十多个工具规模下就已经能省下可观的固定开销。
- 业务页面交互闭环。 挂起、把用户带到某个界面、等他自己动手填表和上传、回报结果再继续。这个原语在"面向业务而非面向工程"的智能体里几乎是必需的，而 harness 类项目普遍没有。
- 引用编号统一重排。 多来源结果合并时，正文里的引用标号需要一次全局偏移修正，否则会串号。
- 组织级并发配额。 就算不做租户计费，"别让一个大客户饿死其他人"也是公共服务的必需品。
写在最后
这两个项目让我确认了一件不太好听但很有用的事：
"Agent 框架"现在是一个被严重过度使用的词。 它同时指代三样不同的东西------面向业务用户的交付平台、面向工程师的智能体内核、面向研究评测的对话脚手架。这三样的架构约束互相冲突，用同一套词汇去比较，结果就是"功能表看起来都能覆盖需求，落地时发现只有一半能用"。
所以选型时最有价值的问题不是"哪个更强"，而是更合适场景。
关于本文的口径
- 对比基于两个仓库的静态代码通读，不是运行态压测或功能实测。
- AIPHarness 取自内部开发分支；DeepSeekHarness 取自一份发布快照，没有提交历史，因此演进速度、issue 治理、社区响应这类维度无法取证，本文不涉及。
- DeepSeekHarness 的版本自述为预发布，本文提到的缺失项（无租户、无计费、无 RAG 等）是它的定位选择，不是缺陷。
- 文中所有"某方没有某能力"的表述，含义是"在本次核对的版本里未找到实现"。