从单点LLM到可靠系统：构建Agentic Harness
Building an Advanced Agentic Harness
基本的LLM调用循环虽然正确，但过于天真。真正的生产级系统需要像空战指挥一样，引入任务规划、并行执行、预算控制和事后复盘。本文展示了如何构建一个高级的Agentic Harness，通过组合typed tools、DAG计划、分层记忆和验证层级，将单一的LLM调用转化为可规划、可执行、可恢复且可验证的可靠系统。我们使用Pydantic进行参数验证，利用DAG实现并行执行，并通过分层记忆管理上下文窗口。最终，我们构建了一个城市比较Agent，展示了如何在保持透明度的同时，实现生产级的稳定性和效率。
这些机制并没有取代飞行员，而是为飞行员提供了结构化的框架，让整个系统保持快速、安全、可调试且可度量。
HN 评论区
43- hanneshdc
有什么基准测试能证明这真的能提升问题解决能力，或者减少错误吗？
这个想法很酷，但根据我在 harness 工程方面的经验，很多听起来很酷的想法往往会因为涌现效应和混淆效应而对性能产生负面影响。
所以我有点怀疑！
- ilaksh
如果我没理解错的话，其中一个 agent 是为每个新任务动态创建 DAG 工作流的？这对我来说是最有趣的部分。其余部分我已经比较熟悉了。
所以也许这就是构建一家“AI 公司”所需的核心部分：一个能够管理目标和层级的 agent。当然，DAG 和 agent 层级并不完全是一回事。但也许真正重要的是工作流和子工作流。
- DerrickDevo1
一篇不错的教程。一般来说，harness 是语言模型与其任务之间的环境层，包括它可以调用的动作集、状态、可见的上下文以及记忆等。
不过，根据我目前的经验，更大的问题其实不在于我们在系统的哪些地方使用 LLM，而在于我们在哪些地方不应当使用 LLM。结果的验证变得越来越重要。大家对此有什么看法？
- bryan0
我（可能像很多人一样）也构建过类似的东西。不过我的主要区别在于，critics 会在开发的每个阶段进行审查，只有通过后才能进入下一阶段。这些阶段由交付物定义：issue、plan、pull request。每个交付物都必须经过 critics 批准，才能进入下一步。因此，整个过程由一个 DAG 定义，规定了如何成功地从一个交付物过渡到下一个。做这个项目挺有意思的，我打算很快开源它，但我猜很多人也在开发类似的系统。
- budududuroiu
> The plan is a graph
我更喜欢给 LLM 一个 REPL 循环，并将所有工具作为函数注入到该 REPL 循环中。
这意味着 LLM 不再受限于编写 DAG，它可以编写包含循环、提前退出等逻辑的代码。