从工具到伙伴：Agent工程化中的Tool、Harness与Skill实践

1. 从"调用工具"到"托付任务"：Agent范式的分水岭在哪

过去两年，我参与过不少Agent相关的项目，从最早的"LLM套个函数调用"到后来逐渐成型的多步规划系统，中间踩的坑比写过的代码还多。如果让我用一句话概括这个领域正在发生的变化，那就是：Agent正在从"工具"变成"伙伴"。这不是一个营销话术，而是工程实践里能明显感知到的分水岭。

什么叫"工具"？你给它一个明确的输入，它给你一个明确的输出，中间不需要它做任何判断。比如你写一个函数get_weather(city)，它只负责查天气，不负责决定"要不要查天气"、"查完天气之后该干什么"。而"伙伴"不一样，你给它一个模糊的目标，比如"帮我看看这周适不适合去露营"，它需要自己拆解：先查天气、再查营地 availability、再对比你的日程、最后给出建议。这中间的每一步，都是它自己决定的。

这个转变听起来很自然，但工程上的难度是指数级上升的。因为一旦Agent开始"自己决定"，你就必须面对三个核心问题：它怎么知道该调用哪个工具？它怎么知道调用失败了该怎么办？它怎么知道什么时候该停下来？这三个问题，分别对应了Tool、Harness和Skill三个关键词，也是我这篇总结想重点聊的东西。

我见过太多团队在Demo阶段跑得飞起，一上生产就各种翻车。翻车的原因往往不是模型不够强，而是Harness层没做好。所谓Harness，你可以理解为"Agent的骨架"——它负责管理上下文、调度工具、处理异常、控制循环。模型是大脑，Harness是神经系统。大脑再聪明，神经断了也白搭。

这篇文章适合谁看？如果你正在做Agent相关的开发，或者正在评估要不要把Agent引入自己的业务，又或者你只是对这个领域好奇、想知道"Agent到底能干什么"，那接下来的内容应该能给你一些实在的参考。我会尽量少讲概念，多讲我在实际项目里遇到的真实问题和解决思路。

2. Tool不是"函数"，而是Agent的"手和脚"

2.1 为什么很多人把Tool设计错了

我见过最常见的错误，就是把Tool当成普通的API来设计。比如做一个"订机票"的Agent，很多人会直接写一个book_flight(from, to, date)的Tool，然后指望模型自己填参数。结果模型要么填错日期格式，要么在用户还没确认的时候就擅自下单。

问题出在哪？Tool不是给程序员用的，是给模型用的。程序员看的文档可以很严谨，参数类型、返回值结构、异常码都写清楚。但模型看的是自然语言描述，它需要知道的是："这个工具是干什么的"、"什么时候该用"、"用了之后会发生什么"。

我现在设计Tool的时候，会强制自己回答三个问题：

• 这个Tool的"触发条件"是什么？不是"参数是什么"，而是"用户在什么情况下应该调用它"。比如book_flight的触发条件应该是"用户明确表达了订票意图，并且已经确认了航班、日期、乘机人信息"，而不是"用户提到了机票"。
• 这个Tool的"副作用"是什么？有些Tool是只读的（查天气），有些是有副作用的（下单、发邮件）。有副作用的Tool必须加确认机制，不能让模型自己决定。
• 这个Tool的"失败模式"是什么？网络超时、参数非法、业务规则拒绝，这三种失败模型应该有不同的处理方式。网络超时可以重试，参数非法需要模型修正，业务规则拒绝则需要告知用户。

2.2 Tool描述里的"隐藏信息"比参数更重要

我举个例子。假设你有一个Tool叫search_flights，参数是from、to、date。如果你只写这些，模型可能会在用户说"我想去三亚"的时候就调用它，然后随便填一个日期。但如果你在描述里加上一句"仅在用户明确提供了出发地、目的地和日期后才调用此工具"，模型的调用准确率会明显提升。

这就是Tool描述里的"隐藏信息"——它不是参数，但它是模型做决策的依据。我通常会在这部分写三类信息：

1. 前置条件：调用这个Tool之前，必须已经满足什么条件。比如"必须先调用get_user_profile获取用户ID"。
2. 后置影响：调用之后会发生什么。比如"此操作会创建订单，不可撤销"。
3. 与其他Tool的关系：比如"如果search_flights返回空结果，应该调用search_flights_fuzzy而不是直接告诉用户没有航班"。

这些信息看起来是"废话"，但对模型来说，它们是决策的关键上下文。我实测下来，加了这些描述的Tool，模型调用准确率能从60%左右提升到85%以上。

2.3 Tool的粒度：太粗和太细都是坑

Tool的粒度设计是个技术活。太粗了，模型不知道怎么用；太细了，模型要调用几十次才能完成一个任务，中间任何一步出错都会导致整个任务失败。

我的经验是：一个Tool应该对应一个"原子业务操作"。什么叫原子业务操作？就是"要么全成功，要么全失败，不需要中间状态"的操作。比如"查询航班"是一个原子操作，"订票"也是一个原子操作，但"查询并订票"就不是——因为查询可能成功但订票失败，中间状态很尴尬。

另外，我建议把"读操作"和"写操作"分开。读操作可以随便调，写操作必须加确认。这样模型在探索阶段可以自由调用读操作来收集信息，到了写操作的时候再让用户确认。这个设计模式我在多个项目里用过，效果很稳。

3. Harness：Agent的"神经系统"到底在管什么

3.1 Harness和Agent的区别：一个容易被混淆的问题

很多人问"Harness和Agent有什么区别"，我一开始也绕了很久。后来我想明白了：Agent是"做什么"，Harness是"怎么做"。Agent定义了目标和策略，Harness负责执行和容错。

举个具体的例子。假设你有一个Agent，目标是"帮用户找到最便宜的机票"。这个目标本身是Agent层面的。但具体怎么找？是先查直飞还是先查中转？查到了之后怎么比价？比价之后怎么呈现？这些是Harness层面的。

Harness通常包含这几个核心模块：

我见过很多项目，Agent的逻辑写得很漂亮，但Harness层几乎是空的。结果就是模型一旦调用工具失败，整个流程就卡死了。或者模型陷入死循环，反复调用同一个工具。这些问题都不是模型的问题，是Harness没做好。

3.2 上下文管理：Agent的"记忆"该怎么管

上下文管理是Harness里最容易被低估的部分。很多人觉得"把对话历史全塞进去就行了"，但实际项目中，上下文窗口是有限的，而且塞得越多，模型越容易"分心"。

我的做法是分层管理：

• 短期记忆：最近3-5轮对话，原样保留。这部分是模型做即时决策的依据。
• 中期记忆：当前任务的中间状态，比如"已经查了3个航班，正在比价"。这部分用结构化格式存储，不占用太多token。
• 长期记忆：用户偏好、历史行为。这部分用向量检索，按需注入。

我实测下来，这种分层方式比"全塞进去"的效果好很多。模型不会被无关信息干扰，同时关键信息也不会丢。

另外，工具调用的返回值也要管理。有些工具返回一大段JSON，直接塞进上下文会占用大量token。我的做法是：只保留模型决策需要的关键字段。比如查航班返回了20个字段，但模型只需要知道"航班号、时间、价格"这三个，那就只保留这三个。

3.3 异常处理：Agent的"容错"是怎么炼成的

异常处理是Harness里最考验工程能力的地方。我总结了几种常见的异常和对应的处理策略：

第一种：工具调用失败（网络超时、服务不可用）

这种最简单，直接重试就行。但重试要有策略：第一次失败等1秒，第二次等2秒，第三次等4秒，最多重试3次。如果还失败，就降级——要么换一个备用工具，要么告诉用户"当前服务不可用，请稍后再试"。

第二种：工具返回结果不符合预期（参数错误、业务规则拒绝）

这种不能简单重试，因为重试还是会失败。正确的做法是把错误信息返回给模型，让模型自己修正。比如模型调用book_flight时日期格式错了，工具返回"日期格式应为YYYY-MM-DD"，模型看到这个信息后会自动修正。

第三种：模型陷入死循环（反复调用同一个工具）

这种最危险，因为会消耗大量token和时间。我的做法是加一个"循环检测器"：如果模型连续3次调用同一个工具且参数相同，就强制中断，并告知模型"你已经尝试过这个操作，请换一种方式"。

第四种：模型"幻觉"（调用了不存在的工具）

这种在早期项目中很常见。解决办法是在Harness层加一个"工具白名单"，模型只能调用白名单里的工具。如果调用了不存在的工具，直接返回错误，让模型重新选择。

3.4 循环控制：什么时候该停

循环控制是Harness里最容易被忽略的部分。很多人只设置了"最大步数"，比如最多10步。但10步到了之后呢？直接返回失败？还是返回中间结果？

我的做法是设置多层终止条件：

1. 目标达成：模型明确表示任务完成。
2. 最大步数：比如15步，到了就强制停止。
3. 用户中断：用户可以随时打断。
4. 异常熔断：连续失败超过阈值，自动停止。

这四层条件里，最重要的是"目标达成"的检测。我通常会让模型在完成任务后输出一个特殊标记，比如[TASK_COMPLETE]，Harness检测到这个标记就停止循环。

4. Skill：Agent的"技能树"该怎么点

4.1 Skill和Tool的区别：一个更抽象的概念

Skill和Tool经常被混用，但我觉得它们有本质区别。Tool是"能力"，Skill是"知识"。Tool是"我能查天气"，Skill是"我知道什么时候该查天气、查完天气之后该怎么用"。

举个例子。你有一个Tool叫search_web，它能搜索网页。但"怎么搜"是一个Skill——是直接搜关键词，还是先拆解问题再搜？搜到结果后怎么筛选？怎么判断信息是否可靠？这些都是Skill层面的东西。

我现在的做法是：Tool用代码实现，Skill用提示词实现。Tool是硬编码的，Skill是软编码的。这样Skill可以随时调整，不需要改代码。

4.2 Skill的编码方式：从"硬提示"到"软技能"

早期我做Agent的时候，把所有提示词都写在一个大prompt里。结果就是prompt越来越长，模型越来越糊涂。后来我学乖了，把提示词拆成多个Skill，每个Skill负责一个具体的子任务。

比如一个"旅行规划"Agent，我会拆成这几个Skill：

• 需求澄清Skill：负责和用户确认目的地、时间、预算。
• 信息收集Skill：负责调用搜索工具收集航班、酒店信息。
• 方案对比Skill：负责对比不同方案的优劣。
• 方案呈现Skill：负责把最终方案用友好的方式呈现给用户。

每个Skill有自己的提示词，Harness根据当前状态决定激活哪个Skill。这样模型每次只需要关注一个子任务，准确率会高很多。

4.3 Skill的复用：怎么避免"重复造轮子"

Skill的复用是个大问题。我见过很多团队，每个Agent都重新写一遍Skill，结果就是大量重复劳动。我的做法是建立一个"Skill库"，把通用的Skill抽出来，比如"需求澄清"、"信息收集"、"方案对比"这些，几乎每个Agent都会用到。

Skill库的管理要注意两点：

1. 版本控制：Skill的提示词会经常调整，必须做版本控制。我通常用Git管理，每次调整都记录原因和效果。
2. 效果评估：每个Skill都要有评估指标。比如"需求澄清Skill"的指标是"用户澄清轮数"，越少越好。

4.4 Skill的"组合"：怎么让Agent学会"举一反三"

单个Skill好写，难的是Skill的组合。比如用户说"帮我规划一个周末旅行"，Agent需要先激活"需求澄清Skill"，再激活"信息收集Skill"，再激活"方案对比Skill"，最后激活"方案呈现Skill"。这个组合逻辑，就是Harness的"调度策略"。

我的做法是用"状态机"来管理Skill的组合。每个Skill执行完后，会返回一个状态，Harness根据状态决定下一个激活哪个Skill。比如"需求澄清Skill"返回"需求已明确"，Harness就激活"信息收集Skill"；如果返回"需求不明确"，就继续激活"需求澄清Skill"。

这种状态机的方式比"让模型自己决定"更可控。模型只需要关注当前Skill的执行，不需要操心全局调度。

5. 工业界实战：那些文档里不会写的坑

5.1 并发问题：Agent扛不住并发怎么办

Agent的并发问题和普通服务不一样。普通服务是无状态的，加机器就行。Agent是有状态的，每个会话都有自己的上下文，不能简单水平扩展。

我遇到过最典型的问题是：多个用户同时调用同一个Agent，上下文串了。比如用户A的对话历史被用户B看到了。这个问题的根源是上下文管理没做好session隔离。

解决办法很简单：每个会话一个独立的上下文实例。不要用全局变量存上下文，用session ID做key，每个session独立管理。另外，如果Agent需要调用外部工具，工具也要支持并发。我见过一个项目，工具层用了单例模式，结果所有请求都排队，延迟高得离谱。

5.2 成本控制：Agent的token消耗怎么降

Agent的token消耗是个大问题。一个复杂的任务，模型可能要调用十几次工具，每次调用都要把上下文重新塞一遍。我算过一笔账：一个简单的旅行规划任务，token消耗可能是普通对话的20倍。

降本的方法有几个：

• 上下文压缩：把历史对话压缩成摘要，减少token占用。
• 工具返回值裁剪：只保留关键字段，不要全量返回。
• 模型分级：简单任务用便宜模型，复杂任务用贵模型。
• 缓存：相同的工具调用结果缓存起来，避免重复调用。

我实测下来，这几个方法组合使用，token消耗能降低60%以上。

5.3 安全边界：Agent不能做什么

Agent的安全边界是个必须严肃对待的问题。我见过一个项目，Agent可以调用"发送邮件"的工具，结果模型被用户诱导，发了一封垃圾邮件给全公司。这个问题的根源是写操作没有加确认机制。

我的原则是：所有有副作用的操作，必须经过用户确认。具体来说：

• 读操作（查询、搜索）：可以直接执行。
• 写操作（下单、发邮件、修改数据）：必须让用户确认。
• 危险操作（删除、转账）：必须二次确认，并且要有额度限制。

另外，Agent的输入也要做过滤。用户可能会输入一些诱导性的内容，试图让Agent执行不该执行的操作。我通常会在Harness层加一个"意图检测"，如果检测到异常意图，直接拒绝。

5.4 效果评估：怎么知道Agent做得好不好

Agent的效果评估比普通模型难得多。普通模型有明确的输入输出，Agent是一个多步过程，中间任何一步出错都会导致最终失败。

我的做法是分步评估：

这几个指标里，我最看重的是"异常恢复率"。因为Agent的价值不在于"一切顺利时能跑通"，而在于"出问题时能自己搞定"。

6. 从工具到伙伴：Agent的下一站在哪

6.1 当前Agent的"能力边界"在哪

说实话，现在的Agent离真正的"伙伴"还有距离。我总结了一下当前Agent的能力边界：

• 能做的：多步规划、工具调用、简单异常处理、信息整合。
• 做不好的：长期记忆、跨会话一致性、复杂推理、创造性任务。
• 不能做的：真正理解用户意图、自主设定目标、处理模糊指令。

这个边界不是模型能力的问题，而是Harness和Skill的问题。模型已经足够强了，但我们的工程实现还没跟上。

6.2 我看到的几个趋势

从工业界的实践来看，Agent的发展有几个明显趋势：

第一，Harness层越来越重。早期大家关注模型，现在大家关注Harness。因为模型的能力已经趋同，差异在工程实现上。

第二，Skill越来越标准化。就像当年的微服务一样，Skill正在从"每个团队自己写"变成"标准化组件"。我预计未来会出现"Skill市场"，大家可以直接买现成的Skill。

第三，评估越来越重要。Agent的效果评估正在从"人工看"变成"自动化评估"。LLM as Judge是一个方向，但还需要更多工程实践。

6.3 给正在做Agent的人几个建议

如果你正在做Agent相关的项目，我有几个建议：

第一，先把Harness做好，再考虑模型。我见过太多团队在模型上花了大把时间，结果Harness一塌糊涂。模型差一点没关系，Harness做好了能补回来。

第二，Tool的设计比数量重要。不要追求Tool的数量，要追求Tool的质量。一个设计良好的Tool，比十个粗糙的Tool有用得多。

第三，Skill要可复用、可评估。不要每个Agent都重新写Skill，建立自己的Skill库，并且给每个Skill定义评估指标。

第四，安全边界要提前想清楚。不要等出了问题再补，一开始就要设计好确认机制和权限控制。

第五，效果评估要自动化。人工评估不可持续，一定要建立自动化的评估体系。

我在实际项目里最大的体会是：Agent的难点不在模型，在工程。模型是给定的，工程是自己做的。把Harness做扎实，把Tool设计好，把Skill管理好，Agent就能从"玩具"变成"工具"，再从"工具"变成"伙伴"。这个过程没有捷径，只能一步步踩坑、一步步填坑。但每填一个坑，Agent就离"伙伴"近一步。