创作于 2026.7.30
最近我用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泉问的回顾终于在正常的时间发出来了，希望没有看到直播的小伙伴也能有所收获。
晚安，各位~