1. 从能插拔到会进化Agent Harness 到底在解决什么问题如果你最近在折腾 AI Agent 相关的东西大概率会碰到一个很尴尬的局面模型能力明明够用但整个系统跑起来就是死板。加一个新工具要改三处配置换一个记忆后端要重写调度逻辑想让它自己总结失败经验对不起得手动把日志喂回去。这种可扩展听起来很美实际上扩展成本高得离谱扩展完还不一定能自洽。Agent Harness 这个词直译过来是智能体挽具或者智能体骨架。你可以把它理解成 Agent 的操作系统外壳——它不负责模型推理本身而是负责把模型、工具、记忆、调度、反馈这几样东西串成一个能持续运转的整体。Pi 和 DSH 在这里是两个阶段的代称Pi 代表的是早期那种插件式的 Harness能力靠外部挂载扩展靠人工配置DSH 代表的是更进一步的形态系统能在运行过程中自己长出新的能力模块、自己调整调度策略、自己沉淀经验。这个演进的核心矛盾其实就一句话扩展性extensibility和自生长self-growth是两回事。可扩展意味着你给它什么它就能用什么自生长意味着它自己知道该长什么。前者是工程问题后者更接近机制设计问题。很多团队卡在 Pi 阶段不是因为工具不够多而是因为所有的生长都得靠人来驱动人一停系统就停。这篇文章适合三类人看一是正在设计 Agent 框架、被加个功能就要动核心代码折磨的工程师二是做 AI 应用、想让 Agent 在真实业务里越跑越聪明的产品技术负责人三是对 Agent 架构演进感兴趣、想搞清楚自生长到底是不是营销话术的从业者。我会尽量把 Pi 到 DSH 这条路径上的关键设计点、踩过的坑、以及可以抄的作业讲清楚不堆概念讲能落地的东西。需要先说明一点标题里的 Pi 和 DSH 是抽象代称不是某个具体开源项目的名字。我下面讲的所有机制都是基于这类系统在常见实践中会遇到的共性问题来展开的具体实现你可以按自己技术栈替换。2. Pi 阶段的真实边界插件化为什么撑不起生长2.1 插件注册表的天花板在哪里Pi 阶段的典型架构是这样的一个中央注册表registry管着所有工具每个工具实现统一的接口调度器根据意图匹配工具执行完把结果塞回上下文。这套东西在工具有限、场景固定的情况下非常好用加一个工具就是写一个类、注册一下、重启服务完事。但问题出在数量和组合上。当工具从 10 个涨到 100 个意图匹配的准确率会肉眼可见地下降因为很多工具的语义边界是模糊的。更麻烦的是组合用户的需求往往需要 A 工具的输出喂给 B 工具再根据 B 的结果决定要不要调 C。Pi 阶段的调度器通常只做单步匹配多步编排要么靠人写死流程要么靠模型在上下文里自己串——前者不灵活后者不稳定。我见过一个很典型的场景一个做数据处理的项目工具列表里有读文件清洗统计画图四个工具。单看每个都能用但用户说帮我把这份数据里异常的部分找出来并可视化调度器就懵了——它不知道该先清洗还是先统计也不知道异常该用哪个工具的哪个参数。最后只能靠人在 prompt 里写死步骤等于把编排逻辑又还给了人。2.2 记忆是存储还是经验差别巨大Pi 阶段的记忆模块绝大多数做的是存储把对话历史存下来把工具调用结果存下来下次需要的时候检索出来塞进上下文。这本质上是 RAG 的思路解决的是信息不丢失的问题。但经验和信息不是一回事。经验是上次这么做失败了所以这次换个做法它需要的是对结果的判断、对失败原因的归因、以及对策略的修正。Pi 阶段的记忆模块通常没有这个能力因为它只存发生了什么不存为什么失败和下次怎么办。结果就是 Agent 会在同一个坑里反复摔每次摔完日志里都有记录但下次跑还是照摔不误。这里有个很隐蔽的坑很多人以为把失败日志也存进向量库就算经验记忆了。实际上检索出来的失败日志模型未必会正确使用——它可能只是把失败日志当成普通上下文然后继续按原来的方式调用工具。经验要生效必须和决策绑定而不是和检索绑定。2.3 人工配置的隐性成本被严重低估Pi 阶段最容易被忽视的成本是配置债。每加一个工具你要写接口描述、写参数 schema、写意图示例、写失败处理每换一个模型你要重新调 prompt、重新测匹配率每上一个新场景你要重新配一遍工具集。这些工作单看都不难但累积起来会形成一个巨大的维护黑洞。更致命的是这些配置是静态的。系统上线后真实流量里的意图分布、工具使用频率、失败模式都在变但配置不会自己变。你得定期人工 review 日志、调整配置、重新上线。这就导致一个悖论系统越用越需要人维护而不是越用越省心。所谓可扩展扩展的是能力上限但维护成本是线性甚至超线性增长的。3. DSH 的自生长机制让系统自己决定长什么3.1 能力缺口识别从人发现到系统发现DSH 阶段第一个要解决的问题就是让系统自己识别我现在缺什么能力。这件事听起来玄其实拆开来看是有章可循的。核心思路是把失败和低效当成信号而不是当成异常。Pi 阶段遇到工具匹配失败通常就是返回一个错误或者兜底回复。DSH 阶段会把这类事件收集起来做聚类分析——如果某一类失败反复出现且现有工具都无法覆盖那就说明存在一个能力缺口。具体怎么做我实践下来比较靠谱的路径是三步失败归因每次任务失败或低效完成记录失败类型匹配失败、参数错误、结果不满足、超时等、上下文特征、以及模型当时的意图。缺口聚类定期对失败样本做聚类找出高频的、现有工具覆盖不了的意图簇。缺口提案对每个显著缺口生成一个能力提案——描述这个能力应该做什么、输入输出大概是什么、和现有工具的关系。这里的关键是第三步不能直接生成代码而是生成提案。提案是给人看的也是给系统自己后续验证用的。直接生成代码风险太高容易引入不可控的行为。3.2 工具自生成与沙箱验证的闭环有了能力提案下一步就是长出对应的工具。这一步是整个 DSH 里技术含量最高、也最容易翻车的环节。我的做法是分三层验证语法层生成的工具代码必须能通过静态检查接口签名必须符合 Harness 的规范。行为层在沙箱里用构造的测试用例跑一遍确认输入输出符合提案描述。集成层把新工具挂到 Harness 上用历史失败样本回放看是否能解决原来的问题。三层都过了才允许新工具进入试用期——试用期内它的调用会被重点监控一旦出现异常行为立即下线。这个机制的本质是灰度发布只不过发布的对象是系统自己生成的工具。注意工具自生成一定要有回滚能力。我见过一个项目系统自己生成了一个删除文件的工具结果因为参数校验没做好把测试数据全清了。沙箱验证必须覆盖破坏性操作且生产环境要有权限隔离。3.3 调度策略的自我修正从规则到反馈Pi 阶段的调度基本是规则匹配DSH 阶段要让它变成反馈驱动。具体来说每次调度决策选哪个工具、传什么参数、要不要多步都会产生一个结果信号这个信号会被用来更新调度策略。实现上可以用一个轻量的打分模型对每个意图-工具组合维护一个成功率、平均耗时、平均成本调度时综合这些指标做选择。新工具初始分数设低一点随着成功调用逐步提升。这样系统会自然倾向于用验证过好用的工具同时给新工具留出探索空间。这里有个反直觉的点不要追求调度策略的全局最优。因为真实场景的意图分布是动态的全局最优很快就过时了。更稳的做法是维护一个局部最优探索的平衡类似多臂老虎机的思路。我试过纯贪心策略前期效果好后期因为过度依赖少数工具遇到新场景就崩加上探索机制后长期表现明显更稳。4. 记忆的进化从存下来到用得上4.1 经验记忆的结构化设计DSH 阶段的记忆核心变化是从非结构化存储转向结构化经验。一条经验记忆至少应该包含这几个字段字段含义示例场景特征触发这条经验的任务特征数据清洗可视化采取策略当时用了什么工具组合先统计后画图结果评价成功/失败/部分成功部分成功失败归因如果失败原因是什么异常检测阈值设错修正建议下次应该怎么调整阈值改为动态计算这样结构化的好处是检索的时候可以按场景特征匹配而不是按语义相似度瞎捞。语义相似度检索在经验记忆上经常翻车因为看起来像的任务实际需要的策略可能完全不同。4.2 经验衰减与冲突消解经验记忆有个绕不开的问题旧经验会过时。三个月前有效的策略现在可能因为工具升级、数据分布变化而失效。如果无脑保留所有经验检索出来的东西会互相打架。我的处理方式是给每条经验加一个时效权重随时间衰减同时被成功复用时权重回升。检索时按权重排序低权重的经验不参与决策但保留在库里。另外当两条经验对同一场景给出冲突建议时不直接删掉任何一条而是标记为冲突对在决策时把冲突信息一起给模型让它结合当前上下文判断。这个设计的好处是保留了系统的记忆多样性避免过早收敛到单一策略。坏处是决策复杂度上升需要模型有足够的判断力。实测下来在模型能力够用的前提下这个 trade-off 是值得的。4.3 跨会话记忆的边界控制跨会话记忆是很多项目的卖点但也是最容易出问题的地方。核心矛盾是记忆越多上下文越丰富但噪声也越大而且有隐私和一致性风险。我的经验是划三条线事实类记忆用户偏好、常用配置可以跨会话长期保留但要定期确认。策略类记忆某类任务怎么做跨会话保留但要有衰减和冲突消解。临时类记忆本次任务的中间状态严格限制在当前会话不跨会话。很多项目把这三类混在一起存结果就是上下文里塞了一堆无关的旧信息模型反而被干扰。分类存储、分类检索是 DSH 阶段记忆模块的基本功。5. 落地路径从 Pi 迁移到 DSH 的实操顺序5.1 先补观测再谈自生长如果你现在跑的是 Pi 阶段的系统想往 DSH 走第一件事不是写自生成模块而是把观测做扎实。没有足够的失败样本、没有清晰的归因数据自生长就是空中楼阁。具体要观测什么至少包括每次任务的意图、调用的工具链、每步的耗时和结果、最终评价、以及失败时的错误类型。这些数据要能按时间、按场景、按工具维度聚合。我见过太多项目日志存了一堆但没法做聚合分析等于白存。5.2 自生成模块的最小可行版本观测到位后可以先做一个最小自生长只做能力缺口识别和提案生成不自动生成代码而是把提案推给人由人来决定要不要实现。这个版本的价值在于验证缺口识别的准确率——如果系统提的缺口人觉得没道理那说明归因逻辑有问题先修这个别急着上自动生成。等缺口识别准确率稳定了再逐步放开自动生成沙箱验证最后才是自动上线灰度监控。每一步都要有回滚和人工兜底别想着一步到位。5.3 调度与记忆的联动调优调度和记忆不是独立的它们要联动。调度决策产生的结果要写回记忆记忆里的经验要影响调度。这个闭环跑通了系统才算真正活起来。调优的时候建议分阶段先固定记忆、调调度再固定调度、调记忆最后一起调。同时调两个变量出了问题根本不知道是谁的锅。我踩过这个坑调了两周没进展分开调三天就定位到是记忆检索的权重设错了。6. 几个容易翻车的细节和我的处理方式6.1 自生成工具的能力漂移系统自己生成的工具用着用着可能会漂移——原本只做 A 的因为参数被滥用慢慢开始做 B。这不是代码变了而是调用方式变了。处理方式是给每个工具加行为边界监控一旦发现调用模式偏离初始设计就触发审查。6.2 经验记忆的自我强化偏差如果系统总是复用某几条高权重经验这些经验会被不断强化形成路径依赖。新场景来了明明有更合适的策略但因为旧经验权重高还是走老路。破解方式是强制保留一定比例的探索性决策即使有高权重经验也偶尔尝试其他路径并把结果写回记忆。6.3 人工干预的接口设计DSH 不是要完全去掉人而是要把人的角色从配置者变成监督者。所以人工干预的接口要设计得足够轻——能一键暂停自生长、能快速 review 提案、能回滚某次自动变更。我见过一个项目自生长模块跑得挺好但因为没有暂停开关出了一次批量错误生成只能整个服务下线损失很大。7. 我个人的几点体会折腾这类系统几年下来最大的感受是自生长不是让系统无人化而是让系统的进化速度跟上场景的变化速度。Pi 阶段的问题是进化靠人推人推得慢系统就落后DSH 阶段是把进化的一部分主动权交给系统但人依然握着方向盘和刹车。另一个体会是别被自生长这个词带偏。它不是让系统凭空长出能力而是让系统在已有能力的基础上通过反馈和组合衍生出新的能力。底层还是那些工具、那些记忆、那些调度逻辑变的是它们之间的连接方式和更新机制。最后说个实操建议如果你现在还在 Pi 阶段别急着推翻重来。先把观测和归因做扎实这是所有后续工作的地基。地基不牢自生长模块建得再漂亮也是沙上塔。等观测数据能稳定支撑决策了再一步步往上加每一步都留好回滚路径。这样走下来从 Pi 到 DSH 不是一次豪赌而是一串可验证的小步迭代。