最近我用Agent做的事情越来越多。

写代码、整理资料、做活动方案，很多事都可以交给Agent。

有些任务交出去后，过一会儿回来一看，结果已经能直接上手了。

但也有些时候，它看起来很忙，工具切了不少，过程也很热闹，最后交上来的东西，却跟真正想要的结果差得很远。

一开始，我会把这种差距归结为模型不够稳定。

后来用得多了，感觉不全是。

同一个模型，任务有没有说清楚、上下文怎么准备、工具和权限怎么配置、结果由谁检查，都会直接影响最后的效果。

很多时候，真正拉开差距的，并不是又换了一个更强的模型，而是有没有给Agent搭好一套干活的环境。

也就是 Harness。

周三晚上，我借着AI泉问第3期，结合社群小伙伴的疑问，把这几个问题集中梳理了一遍。

这一期聊了5个问题：怎样定义任务、准备上下文、划分人机边界，以及如何把一次有效的协作沉淀下来。

同一个Agent，为什么不同人用起来差距很大？

有的人用Agent，生成的内容很多，格式也很整齐，但读完总感觉有点空。

为了得到想要的结果，只能不断补充、修正，每次使用都像重新开始。

另外一些人用起来却很顺。

Agent知道他想要什么，也了解他的习惯，给出的结果越来越接近真实工作需要。

差距不一定都来自模型。

如果只是给Agent发一句话，然后等它返回结果，本质上还是把Agent当成一个更复杂的大模型在用。

Agent真正能不能干活，还取决于模型之外的东西。

任务怎么定义、上下文怎么提供、工具能不能调用、人在哪些节点参与、结果如何校验、失败之后怎么办，这些放在一起，就是Harness。

所以我很赞同前一阵提出的：

Agent = 大模型 + Harness

大模型决定能力上限，Harness决定这些能力能不能在真实任务里稳定发挥出来。

一个模糊想法如何变成可执行任务？

我们平时很容易对Agent说：

• 帮我运营一下账号。
• 帮我分析一下市场。
• 帮我整理一下客户信息。

这些听起来像任务，其实只是想法。

人拿到这种要求，可能会结合经验理解，也可能继续追问。

但Agent很容易自己猜，而且猜错之后还会一本正经地往下做。

我平时更习惯从五个方面把任务说清楚：

• 背景
• 目标
• 结果
• 边界
• 验收

拿“帮我整理客户信息”这句话来说，光这么说其实远远不够。

至少还得补清楚几个关键点：

• 整理这些信息究竟是拿来做什么的
• 要从哪些沟通记录中提取
• 需要识别的是哪一类客户
• 最后要输出成什么格式
• 哪些内容明确不能自行推断

如果每个判断都要注明原文依据，无法确认的内容标记为“待人工判断”，Agent就不容易凭空补全。

这套方法其实也不新。

以前做项目管理、产品设计，同样要把任务交代清楚。

5W2H、SMART，本来就在解决这类问题。

AI并没有让任务定义消失，反而把这件事变得更重要了。

应该给Agent什么上下文？

很多人想到上下文，第一反应就是多给资料。

但说实话，上下文不是越多越好。

一下子扔进去几十份文档，Agent不一定理解得更深，也可能只是找不到重点。

我更愿意把上下文理解成Agent的工作环境。

它既要知道企业资料、产品信息和历史案例，也要知道这一次具体要做什么、当前进行到哪一步、有哪些规则不能碰，以及什么样的结果才算合格。

这里面既有长期维护的知识库、规则和个人偏好，也有当前任务的输入材料和执行状态。

长任务尤其要注意“落盘”

特别是长任务，执行到一半最好及时“落盘”。

已经完成了什么，形成了哪些结论，还剩哪些问题，都记录下来。

后面即使对话变长或者Agent跑偏，也能回来查看当前状态，不至于从头再猜一遍。

所以，上下文管理归根结底不是“把资料都给它”。

而是让Agent在正确的时间，看到正确的信息。

人和Agent应该怎么分工？

以前聊AI替代，经常按岗位划分。

前端会不会被替代，产品经理会不会被替代，销售又会不会被替代。

后来我感觉，这个分析单位还是太大了。

我在世界人工智能大会听过一个案例。

一个团队用AI改造工业流程，并不是直接做完整的“手机贴膜”，而是继续向下拆，只解决“把膜撕起来”这样一个很小的工艺。

这个做法给我的启发挺大。

人和Agent协作，也不应该按岗位分工，而应该拆到具体的任务单元。

一个岗位里，有些任务输入清楚、过程可拆、结果一眼能验证，出错之后也能恢复，就很适合交给Agent。

还有些任务涉及目标选择、规则冲突、对外承诺或者不可逆操作，就应该由人控制。

我平时会看两个维度：

• 任务是否清晰
• 风险是否可控

任务越清晰、风险越低，越可以让Agent自主执行。

任务越模糊、风险越高，人参与得就应该越深。

尤其是删数据库、付款、对外发布这类操作，现阶段还是别放得太开。

省下来的那点时间，真不一定够填坑。

一次成功协作，怎么沉淀下来？

这可能是最容易被低估的一步。

很多人做出一个不错的结果，会把提示词复制出来，放进文档，下次接着用。

有用，但往往不够。

因为一次任务能够成功，不一定只是提示词写得好。

可能还用了特定的资料、规则、工具、人机协作流程和验收方法，也可能中间踩过几个坑，只是最后修正了。

所以我更愿意沉淀一个“任务能力包”。

里面不只有提示词，还应该包括：

• 任务定义
• 所需上下文
• 执行流程
• 评价规则
• 已经发现的异常和处理经验

形式倒没那么重要。

可以做成Skill，也可以是一个Agent角色、一套工作流，甚至是一份整理清楚的文档。

关键是下次遇到同类任务时，它能不能把这次成功相对完整地复现出来。

我常用的过程是：

• 先复盘这次为什么有效
• 再去掉只属于当前客户或当前活动的信息
• 抽象成可以复用的结构
• 然后固化
• 换一个同类任务复测
• 最后继续迭代

复测这一步，我自己有时候也会偷懒。

但就像开发时自己写的代码往往测不出自己的Bug，一个方法只在原任务上好用，也可能只是“过拟合”了。

结尾

好了，这期AI泉问的回顾终于在正常的时间发出来了。

希望没有看到直播的小伙伴也能有所收获。

晚安，各位~