你的Agent脚手架，可能过度设计了

我在构建Agent系统时踩过大坑：工具链越铺越大，最终它变成了一台官僚机器。每加一个功能都要走好几道流程，产出的噪音远远多于信号。

什么是Agent harness？简单说，就是为Agent写的支撑代码：工具调用、上下文管理、重试逻辑、日志追踪……单独看都有道理，合在一起就成了没人能改动的巨兽。

每个组件背后都藏着一个假设。假设用户会频繁切换工具，假设模型经常超时，假设权限控制必须严格。但真实使用场景可能根本不需要这些。我的教训是：假设堆叠起来，就是负担。

国内很多人开发Agent应用，一上来就套LangChain、LangGraph、Dify，再加上向量库和编排引擎。结果呢？调试一次错误要翻好几种框架的源码，改一个提示词都要担心管道会不会断。这让我想起早期用SSH写脚本的团队，被强制迁移到微服务后的痛。复杂，不等于强大。

问题的核心在于，我们用“防御性设计”取代了“验证性设计”。一开始每个假设都合理，但假设需要被验证，而不是被固化。当新代码必须迁就旧假设时，假设就变成了债务。

怎么避免？三个原则：

1. 从最小系统开始。先写能跑的脚本，再考虑抽象。别让框架替你思考。
2. 每个假设都有保质期。定期问：这个组件真的服务了实际调用吗？没有就删。
3. 听信号，别听噪音。日志不是越多越好，指标不是越全越好。能帮助你决策的才是信号。

我现在把Agent harness精简到了三块：一个调用入口、一层错误处理、一份日志记录。功能反而更稳定，改动也更痛快。

Agent脚手架是手段，不是目的。手段越重，目的越模糊。保持轻量，你才能真正听到Agent在说什么。