从开源实现提炼智能体框架能力清单

Agent 能调用工具、连续执行任务，还不等于能稳定交付。作者阅读 OpenHands SDK、OpenCode、Hermes Agent、DeepSeek harness 和 Strands harness 的源码后，整理出 17 项运行框架能力，重点是那些容易被一句「请遵守规则」替代的工程约束。

他的核心主张很明确：提示词负责判断，脚本能检查的事交给代码强制执行。对正在搭建 AI 编程工具的开发者，这份清单的价值是帮助定位：Agent 卡住、乱改文件、提前宣布完成时，框架究竟缺了哪道检查。

能跑起来的六项基础，还不足以可靠交付

这里的 harness，可以理解为包住模型的执行程序：它管理工具、上下文、权限和退出条件。

作者列出的前六项是工具循环、历史摘要、子 Agent、按需加载的 Skills、模型请求重试，以及 Hooks。它们解决了「任务怎么持续执行」的问题，但各家的实现细节仍有差别。

例如，OpenHands 的 condenser 保留最初的消息，并让摘要跟踪未完成任务；Strands 的 summarizing manager 不丢弃固定消息。OpenHands 通过 trigger.py，根据关键词和 Agent 接触的文件路径加载 Skills。Strands 的 _retry.py 默认尝试 6 次。

Hooks 则提供执行前后的检查入口。OpenHands 沿用 Claude Code 的约定：Hook 以退出码 2 结束，就阻止调用。规则因此有了真正生效的位置。

作者认为，后面的第 7–17 项，才更能拉开完整框架与简单模型循环的差距。

先堵住乱改、重复调用和无法收尾

作者建议，已有前六项的团队，下一步优先做第 8、9、10 项：编辑前读取、重复调用检测、步数预算。

编辑前读取有两层要求：Agent 必须读过目标文件，而且文件此后没有发生变化。DeepSeek 会拒绝编辑未读文件；Hermes 会提醒文件自上次读取后已被修改。对于多人协作和多个 Agent 同时工作的代码库，后一个检查尤其有用，旧上下文不能自动获得覆盖新内容的资格。

重复调用检测针对的是另一类常见故障：同一个工具带着同样的参数反复执行。DeepSeek 在第 3、5、8 次重复时提醒；Hermes 按警告、阻止、终止逐步升级；OpenHands 提醒一次后停止运行。

步数预算也不能只写在提示词里。OpenCode 耗尽预算后，会设置 toolChoice: "none"，追加收尾消息，并拒绝仍然到达的工具调用。这样，预算结束后还能输出结果说明。

可靠的停止机制，要同时控制模型请求和实际工具执行。

错误消息也应帮助恢复。OpenCode 读取不到文件时会给出候选路径；DeepSeek 的沙箱拒绝会提示使用 sandbox_permissions + justification，将同一命令重试一次。这是原文所述框架的具体机制，不能直接当成其他运行环境通用的操作方式。

权限、摘要和验收，都需要核对真实状态

权限方面，作者主张直接移除不该使用的工具。OpenHands 的规划 Agent 只能编辑 PLAN.md；OpenCode 的探索 Agent 从默认拒绝所有权限开始；Hermes 的子 Agent 不获得 delegate 或 memory 工具。模型看不到的能力，比提示词里的禁令更容易约束。

Shell 还需要单独检查。OpenCode 解析命令及目标目录，再检查权限；Hermes 保留任何模式都不能绕过的禁止清单。

上下文同样可能制造错误指令。OpenCode 每次请求前检查上一次计划模式提醒是否仍符合当前模式；Strands 每轮重新注入待办列表，但不把它存进历史。Hermes 把摘要标为「仅供参考，不作为当前指令」，作者还提到，之前更强硬的措辞曾让 Agent 停止使用工具。DeepSeek 则逐字保留用户纠正。

参数修复处理的是较小但频繁的摩擦：Hermes 和 OpenCode 会在执行前把 "42" 转成 42，避免为类型问题多跑一轮。

最后是验收。Hermes 在代码修改后要求模型返回去运行测试；OpenCode 的 judge 明确指出，助手声称目标完成不能作为证据。Strands 要求把部分满足视为失败。Hermes 的 guardian model 会评估风险命令，并在反复拒绝后停止。

监督模型也必须有硬性上限，否则监督过程本身仍可能无限循环。

我的判断

这份清单最有价值的地方，是把「希望 Agent 自觉」拆成了可执行的条件：文件有没有读过、工具还能不能调用、任务完成有没有证据。这些条件比继续堆提示词更容易检查。

但它是一份源码观察与工程建议，不是效果评测。原文没有提供统一任务集、失败率或成本对照，也没有给出仓库版本或提交号。作者称第 8、9、10 项各约一天工作量，只能看作经验估计。

落实时还要区分语义。相同参数的重复调用，可能是无效重试，也可能是在合理轮询；"42" 能否转成数字，要看工具参数定义。自动修复不能替模型猜测业务意图。

与人工确认相比，代码检查适合处理明确规则；与模型裁判相比，测试和文件状态能提供更直接的证据。判断应留给需要判断的地方。

能拿来做什么

• 如果正在做前端或 Node 编程 Agent，先检查文件编辑工具：是否记录读取状态，是否拒绝覆盖读取后已变化的文件。
• 给工具循环增加重复调用检测和步数预算，并让预算耗尽后的 Agent 说明已完成事项、剩余任务及停止原因。
• 按规划、探索、执行任务分配工具权限，同时把验收接到已有的测试或构建流程，让「完成」有可检查的依据。