1. 当工具不再是瓶颈，瓶颈就变成了人这两年跟不少做技术、做产品的朋友聊，大家有一个共同的感受：智能体（Agent）的能力边界扩张得太快了。去年还在为能自动调用几个API、串起一条简单工作流而兴奋，今年已经能看到能自主拆解任务、多轮反思、跨工具协作的复杂系统在跑。写代码、查资料、做分析、生成内容，甚至帮你规划行程、整理会议纪要，这些事它都能干，而且干得越来越像样。但奇怪的是，工具越强，很多人反而越焦虑。焦虑的点不在于“它会不会取代我”，而在于“我到底该让它干什么”。你会发现，当执行成本趋近于零的时候，真正卡住你的不再是“怎么做”，而是“做什么”和“做到什么程度算完”。这就像你手里突然有了一把万能钥匙，但你面前有一万扇门，你不知道该开哪一扇，也不知道开到哪里就该停手。这个项目标题说的就是这件事：Agent越来越强之后，真正稀缺的是定义问题和知道何时停下。这不是一句鸡汤，而是一个正在发生的、非常具体的工程现实和认知挑战。它适合所有正在用Agent做实际项目的人——不管你是开发者、产品经理，还是把Agent当成日常助手的重度用户。因为只要你开始依赖它完成复杂任务，你就一定会撞上这两个问题：第一，你怎么把模糊的需求翻译成它能执行的精确指令；第二，你怎么判断它什么时候该继续、什么时候该收手。我自己的体会是，过去我们花80%的时间在“实现”上，现在可能要把80%的时间花在“定义”和“边界控制”上。这个转变不是每个人都能顺利完成的，因为它要求你从“执行者”变成“架构师”和“裁判”。下面我就把这几年踩过的坑、总结的方法，掰开揉碎了讲一讲。2. 为什么“定义问题”成了新的核心竞争力2.1 从“给指令”到“给约束”：一个真实的认知转变以前我们用工具，习惯的是“给指令”。比如让某个脚本跑一下，你会说“把这个文件夹里的图片都压缩到500KB以下”。指令清晰、边界明确、结果可验证。但Agent不一样，它更像一个能力很强但需要引导的实习生。你如果说“帮我优化一下这个项目的图片资源”，它可能会去压缩图片，也可能会去换格式，还可能会去删掉它认为“没用”的图片——而最后这个操作，很可能不是你想要的。这就是定义问题的第一个难点：Agent的自主性越强，你的指令里隐含的约束就越重要。你不能只告诉它“做什么”，还得告诉它“不能做什么”、“优先做什么”、“做到什么程度就停”。我见过一个团队，让Agent去自动修复代码里的lint错误，结果Agent不仅修了错误，还顺手把一些它认为“风格不好”的代码重构了，导致代码审查时diff大得没法看。问题出在哪？出在定义任务的时候没有加约束：“只修复lint报错，不允许改动任何非报错行的逻辑”。所以我现在定义任务，会强制自己写清楚三件事：目标状态、禁止操作、验收标准。目标状态是“我要什么”，禁止操作是“你不能碰什么”，验收标准是“我怎么知道你做完了”。这三件事写不清楚，Agent越强，跑偏得越离谱。2.2 定义问题的本质：把“我想要”翻译成“可执行”很多人觉得定义问题就是写一段清晰的提示词。但实际做下来，提示词只是最表层的东西。真正的定义问题，是把一个模糊的、带有个人偏好的、上下文依赖极强的“我想要”，翻译成一个Agent能理解、能执行、能验证的“可执行规格”。举个例子。你说“帮我写一份周报”。这句话对人来说可能够了，因为人知道周报大概是什么格式、什么粒度、给谁看。但Agent不知道。它可能会写一篇800字的散文，也可能会列一个干巴巴的清单。你得告诉它：受众是谁（给直属领导看还是给全组看）、篇幅大概多少（300字还是1000字）、重点突出什么（进度还是风险）、格式偏好（分点还是段落）、语气（正式还是简洁）。这些信息你脑子里都有，但你不说出来，Agent就只能猜。而猜的结果，十有八九不是你想要的。我自己的做法是，在定义任何稍微复杂一点的任务时，强迫自己回答五个问题：这个任务的输入是什么？是文件、链接、一段文字，还是多个来源的混合？输出长什么样？格式、结构、长度、语气，能描述多细就多细。有哪些硬性约束？时间、预算、不能用的工具、不能碰的数据。怎么判断做完了？是有一个明确的检查清单，还是需要我人工确认？如果中途卡住了怎么办？是让它停下来问我，还是按某个默认策略继续？这五个问题回答完，你会发现原本模糊的需求变得非常具体。而这个过程，恰恰是Agent替代不了的。它可以帮你执行，但没法帮你决定“什么才是对的”。2.3 一个反直觉的发现：定义得越清楚，Agent反而越“笨”这里有一个很有意思的悖论。当你把任务定义得非常精确的时候，Agent的表现反而可能不如你给它一点模糊空间。为什么？因为过度精确的定义会限制它的搜索空间和推理能力。比如你让它“用A方法解决B问题”，它可能就真的只试A方法，而不会去想C方法是不是更好。所以定义问题不是越细越好，而是要在“约束”和“自由”之间找到平衡点。我的经验是：目标和边界要极其清晰，路径和方法可以留白。你告诉它“我要在明天中午前拿到一份关于某个主题的调研报告，不少于2000字，引用不少于5个来源，不允许编造数据”，但不要告诉它“你先搜A网站再搜B网站然后用C模板写”。前者是定义问题，后者是定义解法。定义问题是你的活，定义解法是它的活。这个平衡点怎么找？我的做法是，先给一个相对宽松的定义，看它跑出来的结果，然后根据偏差逐步收紧约束。跑两三次之后，你就能找到那个“既不会跑偏、又不会僵化”的甜点区。这个过程本身，就是你在训练自己对任务的理解深度。3. “知道何时停下”为什么比“知道怎么开始”更难3.1 Agent的“过度执行”倾向：一个必须正视的工程现实如果你用过足够多的Agent，你一定会发现一个现象：它特别容易“过度执行”。你让它查一个数据，它查完数据之后顺便帮你分析了趋势，分析完趋势之后又给你提了三条建议，提完建议之后还问你要不要它直接写一份报告。你本来只想要一个数字，结果它给了你一份咨询方案。这种过度执行，在演示的时候看起来很酷，但在实际项目里往往是灾难。因为它消耗了额外的token、额外的时间，还可能引入你不想要的错误。更麻烦的是，它有时候会“自作主张”地修改一些你不希望它碰的东西。比如你让它整理一份文档，它可能顺手把文档的格式全改了；你让它跑一个测试，它可能顺手把测试数据也改了。为什么会这样？因为Agent的底层逻辑是“最大化完成任务的可能性”。它被训练成要“有帮助”，所以它会倾向于做更多。但“有帮助”和“符合预期”之间，是有差距的。知道何时停下，本质上是在对抗它的这种倾向。3.2 停下的三个信号：什么时候该喊“卡”那怎么判断它该停了呢？我总结了三个信号，只要出现其中一个，我就会让它停下来。第一个信号：目标已经达成，但它在继续“优化”。比如你让它把一段文字翻译成英文，它翻译完了，然后开始给你解释为什么这么翻译，又给你提供了两个备选版本，还问你要不要调整语气。这时候目标已经达成了，后面的都是冗余。你要做的是明确告诉它“翻译完成即停止，不需要额外解释和备选”。第二个信号：它开始处理你没有提供的输入。比如你让它分析一份销售数据，它分析完之后，开始去网上搜行业平均数据来做对比。这个行为本身可能是有价值的，但它超出了你定义的边界。如果你没有授权它去外部搜索，它就不应该做。这时候要停下来，要么明确授权，要么明确禁止。第三个信号：它开始重复之前的步骤。这是最明显的信号。Agent在陷入循环的时候，往往会反复执行同一个操作，或者反复输出类似的内容。这时候不要犹豫，直接打断，然后检查你的任务定义是不是有歧义，或者它是不是卡在了某个它无法解决的子问题上。3.3 怎么在工程上实现“知道何时停下”光靠人盯着看是不现实的，尤其是当Agent跑长任务的时候。你需要在工程层面给它加上“刹车机制”。我常用的有三种。第一种是硬性步数限制。给Agent设定一个最大执行步数，比如20步。超过20步还没完成，就强制停止并输出当前状态。这个数字怎么定？看任务复杂度。简单的信息查询3到5步，中等复杂度的分析任务10到15步，复杂的多阶段任务可以放到30步。但一定要有上限，不然它可能会跑到天荒地老。第二种是检查点机制。在任务的关键节点设置检查点，让Agent在到达检查点时输出当前进展，并等待确认。比如“完成数据收集后停下来”、“生成初稿后停下来”、“修改超过3处后停下来”。这样你可以在关键节点介入，避免它一路跑到黑。第三种是完成度自评。让Agent在每一步之后评估自己的完成度，如果连续两步完成度没有提升，就自动停止。这个机制需要你在提示词里明确要求它做自评，比如“每完成一步，评估当前结果与目标的差距，如果差距没有缩小，停止执行并报告”。这三种机制可以组合使用。我自己的项目里，通常是硬性步数限制加上检查点机制，简单任务用前者，复杂任务用后者。4. 从“执行者”到“架构师”：一个可落地的实操框架4.1 任务定义模板：把模糊需求变成可执行规格说了这么多理念，落到实操上，我整理了一个任务定义模板。每次要Agent做稍微复杂一点的事情，我都会先填这个模板。填完再发给它，跑偏的概率会大幅降低。字段说明示例任务目标一句话说清楚要什么整理一份关于某主题的调研摘要输入来源明确它能用什么仅限我提供的三份文档，不允许外部搜索输出格式结构、长度、语气分点列出，不超过500字，客观语气硬性约束不能做什么不允许编造数据，不允许添加个人观点验收标准怎么算完成包含至少3个关键发现，每个发现有一句话解释停止条件什么时候停输出完成后立即停止，不需要额外建议异常处理卡住了怎么办如果信息不足，列出缺失项并停止这个模板看起来简单，但填起来你会发现很多你原本没想清楚的地方。比如“验收标准”这一栏，很多人第一次填的时候会写“写得好就行”。但“好”是什么？是逻辑清晰？是数据准确？是语言流畅？你不定义清楚，Agent就只能按它的理解来。4.2 边界控制的四种模式：从“全自动”到“全手动”根据任务的风险程度和你的信任程度，边界控制可以分为四种模式。我一般会根据任务类型来选择。全自动模式：Agent自主执行，不需要人工介入。适合低风险、高重复性的任务，比如格式转换、数据清洗、批量重命名。这种模式下，你只需要设定好硬性步数限制和异常处理策略就行。检查点模式：Agent在关键节点停下来等你确认。适合中等风险、需要人工判断的任务，比如内容生成、代码修改、数据分析。这种模式下，检查点的设置很关键，设得太密会打断它的思路，设得太疏又起不到控制作用。我的经验是，在一个任务的自然阶段边界设检查点，比如“收集完资料后”、“写完初稿后”、“修改完第一轮后”。审批模式：Agent只做分析和建议，所有实际操作都需要你审批。适合高风险任务，比如涉及资金、涉及对外发布、涉及不可逆操作。这种模式下，Agent更像一个参谋，而不是一个执行者。全手动模式：Agent只提供信息，所有决策和操作都由你完成。适合探索性任务，比如你还不确定要做什么，只是想让它帮你搜集一些信息、提供一些思路。这种模式下，Agent的价值在于扩展你的信息面，而不是替代你的决策。这四种模式不是固定的，同一个任务在不同阶段可以用不同模式。比如一个内容创作任务，前期用全手动模式做调研，中期用检查点模式写初稿，后期用全自动模式做格式调整。4.3 一个完整的实操案例：从定义到停止的全过程为了让你更直观地理解，我拿一个实际做过的项目来拆解。任务背景是：我需要从一堆用户反馈里提取出关键问题，并生成一份分类报告。第一步，定义问题。我填的任务定义模板是这样的：目标是“从提供的200条用户反馈中提取关键问题，并按功能模块分类”；输入来源是“仅限我提供的反馈文件，不允许外部搜索”；输出格式是“每个模块下列出问题，每个问题附上出现频次和一条典型反馈”；硬性约束是“不允许编造反馈，不允许合并语义不同的问题”；验收标准是“覆盖至少80%的反馈，分类不超过5个模块”；停止条件是“输出完成后停止，不需要额外建议”；异常处理是“如果反馈语义模糊无法分类，单独列出并停止”。第二步，设定边界。我选择了检查点模式，在“提取完关键问题后”和“分类完成后”设了两个检查点。同时设了硬性步数限制15步。第三步，执行和监控。第一轮跑下来，它在提取关键问题阶段就卡住了，因为有些反馈同时涉及多个问题。它试图把一条反馈拆成多个问题，但拆得比较碎。我在第一个检查点介入，告诉它“一条反馈最多拆成两个问题，如果超过两个，选择最主要的那个”。调整之后，第二轮就顺畅多了。第四步，判断停止。它在分类完成后，开始尝试给每个问题提改进建议。这超出了我的定义，我直接让它停止，并输出最终报告。最终报告的质量比我预期的好，因为它没有在“提建议”上浪费精力，而是把精力都放在了“提取”和“分类”上。这个案例的关键点在于：定义问题的时候把“不做什么”写清楚，比把“做什么”写清楚更重要。因为Agent的能力太强了，你不给它画边界，它就会自己画，而它画的边界往往不是你想要的。5. 常见问题与排查技巧实录5.1 Agent跑偏了怎么办：五个排查方向即使你定义得再清楚，Agent还是有可能跑偏。这时候不要急着改提示词，先按下面五个方向排查一遍。方向一：任务定义里有没有歧义？这是最常见的原因。比如你说“整理一下这些数据”，它可能理解为“清洗数据”，也可能理解为“汇总数据”。检查你的定义里有没有这种模糊词汇，有的话换成更具体的表述。方向二：约束条件是不是不够硬？你说“尽量不要编造数据”，它可能理解为“可以编造一点点”。把“尽量”去掉，换成“不允许”。你说“简短一点”，它可能理解为“比之前短”，也可能理解为“不超过100字”。把模糊的约束换成可量化的约束。方向三：检查点是不是设得太少？如果它跑了很久你才发现跑偏，说明检查点设少了。在任务的自然阶段边界加检查点，让它有机会在跑偏的早期就被拉回来。方向四：它是不是遇到了它解决不了的子问题？有时候跑偏不是因为它不理解任务，而是因为它卡住了，然后开始“自由发挥”。这时候你要么帮它解决那个子问题，要么调整任务范围，绕开那个子问题。方向五：你的验收标准是不是它理解不了？你说“质量要高”，它不知道什么叫“高”。你说“要专业”，它也不知道什么叫“专业”。把验收标准换成可检查的条目，比如“包含至少3个数据点”、“每个结论都有来源支撑”。5.2 什么时候该放弃让Agent做这件事不是所有事情都适合交给Agent。我自己的判断标准是：如果一件事你自己都定义不清楚，那就不适合交给Agent。因为Agent的能力再强，也没法帮你定义问题。它只能在你定义好的框架里执行。具体来说，以下几种情况我会放弃用Agent：第一，任务的目标本身还在探索中，我自己都不知道要什么；第二，任务的验收标准高度依赖个人审美或主观判断，比如“写一篇有感染力的文案”；第三，任务的容错率极低，一旦出错后果严重，比如涉及资金操作；第四，任务需要大量的隐性知识，而这些知识很难用文字表达清楚。放弃不代表不用，而是换一种用法。比如对于探索性任务，我会用全手动模式，让Agent帮我搜集信息、提供思路，但决策和判断由我自己来。对于主观性任务，我会用检查点模式，让它生成多个版本，我来挑选和修改。5.3 一个容易被忽略的坑：Agent的“自信错误”Agent有一个很危险的特点：它犯错的时候往往非常自信。它会用同样肯定的语气输出正确和错误的内容。如果你不仔细检查，很容易被它带偏。我踩过的一个坑是：让Agent帮我整理一份技术方案的对比。它输出了一个看起来很专业的对比表格，每个方案都有优缺点分析。我当时觉得挺好，就直接用了。后来才发现，其中两个方案的优缺点它写反了。它并不是故意骗我，而是它在推理的时候搞混了。从那以后，我养成了一个习惯：对于Agent输出的任何事实性内容，尤其是数据、引用、对比结论，我都会抽查验证。抽查的比例不用太高，10%到20%就行，但一定要抽。如果抽查发现错误率超过可接受范围，那就说明这个任务的定义有问题，或者Agent的能力还不足以胜任这个任务。另一个习惯是：让Agent标注它的置信度。在提示词里要求它“对每个结论标注高、中、低置信度，低置信度的结论需要说明原因”。这样你可以快速定位到那些它自己也没把握的地方，重点检查。6. 把“定义”和“停止”变成肌肉记忆6.1 日常训练方法：从简单任务开始刻意练习定义问题和知道何时停下，这两件事都是可以训练的。我的训练方法是从简单任务开始，刻意练习。比如，让Agent帮你查一个数据。这个任务足够简单，但你依然可以练习定义问题：输入来源是什么？输出格式是什么？验收标准是什么？停止条件是什么？查完之后，练习判断停止：它有没有额外输出？有没有超出你的定义？再比如，让Agent帮你改一段文字。练习定义：改什么？不改什么？改成什么样算好？练习停止：改完之后它有没有继续“优化”？有没有改动你没让它改的地方？这些简单任务花不了多少时间，但能帮你养成习惯。等你面对复杂任务的时候，这些习惯就会自动起作用。6.2 团队协作中的经验：怎么让别人也能定义清楚如果你是团队里负责跟Agent打交道的人，你还需要把这种能力传递给其他人。我的经验是，不要指望每个人都能写出好的任务定义。更现实的做法是，提供一个模板，然后要求大家填完模板再提交任务。模板不用太复杂，就是前面说的那七个字段。填完之后，由你来审核一遍，看看有没有歧义、有没有遗漏约束、验收标准是不是可检查。审核的过程本身，就是在帮团队建立对任务定义的共识。另外，我会在团队里维护一个“跑偏案例库”。每次有人遇到Agent跑偏的情况，就把案例记下来：任务定义是什么、跑偏的表现是什么、最后怎么解决的。这个案例库积累到二三十条的时候，团队里大部分人就能避开80%的常见坑了。6.3 一个值得坚持的原则：宁可慢一点，也要定义清楚最后分享一个我自己的原则：宁可花10分钟定义问题，也不要花1小时收拾烂摊子。很多人用Agent的时候，习惯是“先跑起来再说”，觉得定义问题太浪费时间。但实际算下来，定义问题花的时间，远远少于跑偏之后重新跑、重新改、重新检查的时间。而且，定义问题的过程本身，就是在帮你理清思路。很多时候，你以为你想清楚了，但一填模板就发现有很多模糊的地方。这些模糊的地方，如果不提前解决，Agent一定会帮你“解决”——用它的方式，而不是你的方式。所以我现在用Agent，第一步永远是定义问题，第二步永远是设定停止条件。这两步做完，后面的执行反而变得很简单。因为你知道要什么，也知道什么时候该停，剩下的就是让它跑就行了。这个内容后续还可以这样扩展：针对不同类型的任务（比如代码生成、内容创作、数据分析），分别整理出更具体的定义模板和停止条件清单。如果你手头有正在跑的任务，不妨先试着填一遍那个七字段模板，看看能不能把原本模糊的需求写清楚。写不清楚的地方，就是你需要先想清楚的地方。
1. 当工具不再是瓶颈，瓶颈就变成了人这两年跟不少做技术、做产品的朋友聊，大家有一个共同的感受：智能体（Agent）的能力边界扩张得太快了。去年还在为能自动调用几个API、串起一条简单工作流而兴奋，今年已经能看到能自主拆解任务、多轮反思、跨工具协作的复杂系统在跑。写代码、查资料、做分析、生成内容，甚至帮你规划行程、整理会议纪要，这些事它都能干，而且干得越来越像样。但奇怪的是，工具越强，很多人反而越焦虑。焦虑的点不在于“它会不会取代我”，而在于“我到底该让它干什么”。你会发现，当执行成本趋近于零的时候，真正卡住你的不再是“怎么做”，而是“做什么”和“做到什么程度算完”。这就像你手里突然有了一把万能钥匙，但你面前有一万扇门，你不知道该开哪一扇，也不知道开到哪里就该停手。这个项目标题说的就是这件事：Agent越来越强之后，真正稀缺的是定义问题和知道何时停下。这不是一句鸡汤，而是一个正在发生的、非常具体的工程现实和认知挑战。它适合所有正在用Agent做实际项目的人——不管你是开发者、产品经理，还是把Agent当成日常助手的重度用户。因为只要你开始依赖它完成复杂任务，你就一定会撞上这两个问题：第一，你怎么把模糊的需求翻译成它能执行的精确指令；第二，你怎么判断它什么时候该继续、什么时候该收手。我自己的体会是，过去我们花80%的时间在“实现”上，现在可能要把80%的时间花在“定义”和“边界控制”上。这个转变不是每个人都能顺利完成的，因为它要求你从“执行者”变成“架构师”和“裁判”。下面我就把这几年踩过的坑、总结的方法，掰开揉碎了讲一讲。2. 为什么“定义问题”成了新的核心竞争力2.1 从“给指令”到“给约束”：一个真实的认知转变以前我们用工具，习惯的是“给指令”。比如让某个脚本跑一下，你会说“把这个文件夹里的图片都压缩到500KB以下”。指令清晰、边界明确、结果可验证。但Agent不一样，它更像一个能力很强但需要引导的实习生。你如果说“帮我优化一下这个项目的图片资源”，它可能会去压缩图片，也可能会去换格式，还可能会去删掉它认为“没用”的图片——而最后这个操作，很可能不是你想要的。这就是定义问题的第一个难点：Agent的自主性越强，你的指令里隐含的约束就越重要。你不能只告诉它“做什么”，还得告诉它“不能做什么”、“优先做什么”、“做到什么程度就停”。我见过一个团队，让Agent去自动修复代码里的lint错误，结果Agent不仅修了错误，还顺手把一些它认为“风格不好”的代码重构了，导致代码审查时diff大得没法看。问题出在哪？出在定义任务的时候没有加约束：“只修复lint报错，不允许改动任何非报错行的逻辑”。所以我现在定义任务，会强制自己写清楚三件事：目标状态、禁止操作、验收标准。目标状态是“我要什么”，禁止操作是“你不能碰什么”，验收标准是“我怎么知道你做完了”。这三件事写不清楚，Agent越强，跑偏得越离谱。2.2 定义问题的本质：把“我想要”翻译成“可执行”很多人觉得定义问题就是写一段清晰的提示词。但实际做下来，提示词只是最表层的东西。真正的定义问题，是把一个模糊的、带有个人偏好的、上下文依赖极强的“我想要”，翻译成一个Agent能理解、能执行、能验证的“可执行规格”。举个例子。你说“帮我写一份周报”。这句话对人来说可能够了，因为人知道周报大概是什么格式、什么粒度、给谁看。但Agent不知道。它可能会写一篇800字的散文，也可能会列一个干巴巴的清单。你得告诉它：受众是谁（给直属领导看还是给全组看）、篇幅大概多少（300字还是1000字）、重点突出什么（进度还是风险）、格式偏好（分点还是段落）、语气（正式还是简洁）。这些信息你脑子里都有，但你不说出来，Agent就只能猜。而猜的结果，十有八九不是你想要的。我自己的做法是，在定义任何稍微复杂一点的任务时，强迫自己回答五个问题：这个任务的输入是什么？是文件、链接、一段文字，还是多个来源的混合？输出长什么样？格式、结构、长度、语气，能描述多细就多细。有哪些硬性约束？时间、预算、不能用的工具、不能碰的数据。怎么判断做完了？是有一个明确的检查清单，还是需要我人工确认？如果中途卡住了怎么办？是让它停下来问我，还是按某个默认策略继续？这五个问题回答完，你会发现原本模糊的需求变得非常具体。而这个过程，恰恰是Agent替代不了的。它可以帮你执行，但没法帮你决定“什么才是对的”。2.3 一个反直觉的发现：定义得越清楚，Agent反而越“笨”这里有一个很有意思的悖论。当你把任务定义得非常精确的时候，Agent的表现反而可能不如你给它一点模糊空间。为什么？因为过度精确的定义会限制它的搜索空间和推理能力。比如你让它“用A方法解决B问题”，它可能就真的只试A方法，而不会去想C方法是不是更好。所以定义问题不是越细越好，而是要在“约束”和“自由”之间找到平衡点。我的经验是：目标和边界要极其清晰，路径和方法可以留白。你告诉它“我要在明天中午前拿到一份关于某个主题的调研报告，不少于2000字，引用不少于5个来源，不允许编造数据”，但不要告诉它“你先搜A网站再搜B网站然后用C模板写”。前者是定义问题，后者是定义解法。定义问题是你的活，定义解法是它的活。这个平衡点怎么找？我的做法是，先给一个相对宽松的定义，看它跑出来的结果，然后根据偏差逐步收紧约束。跑两三次之后，你就能找到那个“既不会跑偏、又不会僵化”的甜点区。这个过程本身，就是你在训练自己对任务的理解深度。3. “知道何时停下”为什么比“知道怎么开始”更难3.1 Agent的“过度执行”倾向：一个必须正视的工程现实如果你用过足够多的Agent，你一定会发现一个现象：它特别容易“过度执行”。你让它查一个数据，它查完数据之后顺便帮你分析了趋势，分析完趋势之后又给你提了三条建议，提完建议之后还问你要不要它直接写一份报告。你本来只想要一个数字，结果它给了你一份咨询方案。这种过度执行，在演示的时候看起来很酷，但在实际项目里往往是灾难。因为它消耗了额外的token、额外的时间，还可能引入你不想要的错误。更麻烦的是，它有时候会“自作主张”地修改一些你不希望它碰的东西。比如你让它整理一份文档，它可能顺手把文档的格式全改了；你让它跑一个测试，它可能顺手把测试数据也改了。为什么会这样？因为Agent的底层逻辑是“最大化完成任务的可能性”。它被训练成要“有帮助”，所以它会倾向于做更多。但“有帮助”和“符合预期”之间，是有差距的。知道何时停下，本质上是在对抗它的这种倾向。3.2 停下的三个信号：什么时候该喊“卡”那怎么判断它该停了呢？我总结了三个信号，只要出现其中一个，我就会让它停下来。第一个信号：目标已经达成，但它在继续“优化”。比如你让它把一段文字翻译成英文，它翻译完了，然后开始给你解释为什么这么翻译，又给你提供了两个备选版本，还问你要不要调整语气。这时候目标已经达成了，后面的都是冗余。你要做的是明确告诉它“翻译完成即停止，不需要额外解释和备选”。第二个信号：它开始处理你没有提供的输入。比如你让它分析一份销售数据，它分析完之后，开始去网上搜行业平均数据来做对比。这个行为本身可能是有价值的，但它超出了你定义的边界。如果你没有授权它去外部搜索，它就不应该做。这时候要停下来，要么明确授权，要么明确禁止。第三个信号：它开始重复之前的步骤。这是最明显的信号。Agent在陷入循环的时候，往往会反复执行同一个操作，或者反复输出类似的内容。这时候不要犹豫，直接打断，然后检查你的任务定义是不是有歧义，或者它是不是卡在了某个它无法解决的子问题上。3.3 怎么在工程上实现“知道何时停下”光靠人盯着看是不现实的，尤其是当Agent跑长任务的时候。你需要在工程层面给它加上“刹车机制”。我常用的有三种。第一种是硬性步数限制。给Agent设定一个最大执行步数，比如20步。超过20步还没完成，就强制停止并输出当前状态。这个数字怎么定？看任务复杂度。简单的信息查询3到5步，中等复杂度的分析任务10到15步，复杂的多阶段任务可以放到30步。但一定要有上限，不然它可能会跑到天荒地老。第二种是检查点机制。在任务的关键节点设置检查点，让Agent在到达检查点时输出当前进展，并等待确认。比如“完成数据收集后停下来”、“生成初稿后停下来”、“修改超过3处后停下来”。这样你可以在关键节点介入，避免它一路跑到黑。第三种是完成度自评。让Agent在每一步之后评估自己的完成度，如果连续两步完成度没有提升，就自动停止。这个机制需要你在提示词里明确要求它做自评，比如“每完成一步，评估当前结果与目标的差距，如果差距没有缩小，停止执行并报告”。这三种机制可以组合使用。我自己的项目里，通常是硬性步数限制加上检查点机制，简单任务用前者，复杂任务用后者。4. 从“执行者”到“架构师”：一个可落地的实操框架4.1 任务定义模板：把模糊需求变成可执行规格说了这么多理念，落到实操上，我整理了一个任务定义模板。每次要Agent做稍微复杂一点的事情，我都会先填这个模板。填完再发给它，跑偏的概率会大幅降低。字段说明示例任务目标一句话说清楚要什么整理一份关于某主题的调研摘要输入来源明确它能用什么仅限我提供的三份文档，不允许外部搜索输出格式结构、长度、语气分点列出，不超过500字，客观语气硬性约束不能做什么不允许编造数据，不允许添加个人观点验收标准怎么算完成包含至少3个关键发现，每个发现有一句话解释停止条件什么时候停输出完成后立即停止，不需要额外建议异常处理卡住了怎么办如果信息不足，列出缺失项并停止这个模板看起来简单，但填起来你会发现很多你原本没想清楚的地方。比如“验收标准”这一栏，很多人第一次填的时候会写“写得好就行”。但“好”是什么？是逻辑清晰？是数据准确？是语言流畅？你不定义清楚，Agent就只能按它的理解来。4.2 边界控制的四种模式：从“全自动”到“全手动”根据任务的风险程度和你的信任程度，边界控制可以分为四种模式。我一般会根据任务类型来选择。全自动模式：Agent自主执行，不需要人工介入。适合低风险、高重复性的任务，比如格式转换、数据清洗、批量重命名。这种模式下，你只需要设定好硬性步数限制和异常处理策略就行。检查点模式：Agent在关键节点停下来等你确认。适合中等风险、需要人工判断的任务，比如内容生成、代码修改、数据分析。这种模式下，检查点的设置很关键，设得太密会打断它的思路，设得太疏又起不到控制作用。我的经验是，在一个任务的自然阶段边界设检查点，比如“收集完资料后”、“写完初稿后”、“修改完第一轮后”。审批模式：Agent只做分析和建议，所有实际操作都需要你审批。适合高风险任务，比如涉及资金、涉及对外发布、涉及不可逆操作。这种模式下，Agent更像一个参谋，而不是一个执行者。全手动模式：Agent只提供信息，所有决策和操作都由你完成。适合探索性任务，比如你还不确定要做什么，只是想让它帮你搜集一些信息、提供一些思路。这种模式下，Agent的价值在于扩展你的信息面，而不是替代你的决策。这四种模式不是固定的，同一个任务在不同阶段可以用不同模式。比如一个内容创作任务，前期用全手动模式做调研，中期用检查点模式写初稿，后期用全自动模式做格式调整。4.3 一个完整的实操案例：从定义到停止的全过程为了让你更直观地理解，我拿一个实际做过的项目来拆解。任务背景是：我需要从一堆用户反馈里提取出关键问题，并生成一份分类报告。第一步，定义问题。我填的任务定义模板是这样的：目标是“从提供的200条用户反馈中提取关键问题，并按功能模块分类”；输入来源是“仅限我提供的反馈文件，不允许外部搜索”；输出格式是“每个模块下列出问题，每个问题附上出现频次和一条典型反馈”；硬性约束是“不允许编造反馈，不允许合并语义不同的问题”；验收标准是“覆盖至少80%的反馈，分类不超过5个模块”；停止条件是“输出完成后停止，不需要额外建议”；异常处理是“如果反馈语义模糊无法分类，单独列出并停止”。第二步，设定边界。我选择了检查点模式，在“提取完关键问题后”和“分类完成后”设了两个检查点。同时设了硬性步数限制15步。第三步，执行和监控。第一轮跑下来，它在提取关键问题阶段就卡住了，因为有些反馈同时涉及多个问题。它试图把一条反馈拆成多个问题，但拆得比较碎。我在第一个检查点介入，告诉它“一条反馈最多拆成两个问题，如果超过两个，选择最主要的那个”。调整之后，第二轮就顺畅多了。第四步，判断停止。它在分类完成后，开始尝试给每个问题提改进建议。这超出了我的定义，我直接让它停止，并输出最终报告。最终报告的质量比我预期的好，因为它没有在“提建议”上浪费精力，而是把精力都放在了“提取”和“分类”上。这个案例的关键点在于：定义问题的时候把“不做什么”写清楚，比把“做什么”写清楚更重要。因为Agent的能力太强了，你不给它画边界，它就会自己画，而它画的边界往往不是你想要的。5. 常见问题与排查技巧实录5.1 Agent跑偏了怎么办：五个排查方向即使你定义得再清楚，Agent还是有可能跑偏。这时候不要急着改提示词，先按下面五个方向排查一遍。方向一：任务定义里有没有歧义？这是最常见的原因。比如你说“整理一下这些数据”，它可能理解为“清洗数据”，也可能理解为“汇总数据”。检查你的定义里有没有这种模糊词汇，有的话换成更具体的表述。方向二：约束条件是不是不够硬？你说“尽量不要编造数据”，它可能理解为“可以编造一点点”。把“尽量”去掉，换成“不允许”。你说“简短一点”，它可能理解为“比之前短”，也可能理解为“不超过100字”。把模糊的约束换成可量化的约束。方向三：检查点是不是设得太少？如果它跑了很久你才发现跑偏，说明检查点设少了。在任务的自然阶段边界加检查点，让它有机会在跑偏的早期就被拉回来。方向四：它是不是遇到了它解决不了的子问题？有时候跑偏不是因为它不理解任务，而是因为它卡住了，然后开始“自由发挥”。这时候你要么帮它解决那个子问题，要么调整任务范围，绕开那个子问题。方向五：你的验收标准是不是它理解不了？你说“质量要高”，它不知道什么叫“高”。你说“要专业”，它也不知道什么叫“专业”。把验收标准换成可检查的条目，比如“包含至少3个数据点”、“每个结论都有来源支撑”。5.2 什么时候该放弃让Agent做这件事不是所有事情都适合交给Agent。我自己的判断标准是：如果一件事你自己都定义不清楚，那就不适合交给Agent。因为Agent的能力再强，也没法帮你定义问题。它只能在你定义好的框架里执行。具体来说，以下几种情况我会放弃用Agent：第一，任务的目标本身还在探索中，我自己都不知道要什么；第二，任务的验收标准高度依赖个人审美或主观判断，比如“写一篇有感染力的文案”；第三，任务的容错率极低，一旦出错后果严重，比如涉及资金操作；第四，任务需要大量的隐性知识，而这些知识很难用文字表达清楚。放弃不代表不用，而是换一种用法。比如对于探索性任务，我会用全手动模式，让Agent帮我搜集信息、提供思路，但决策和判断由我自己来。对于主观性任务，我会用检查点模式，让它生成多个版本，我来挑选和修改。5.3 一个容易被忽略的坑：Agent的“自信错误”Agent有一个很危险的特点：它犯错的时候往往非常自信。它会用同样肯定的语气输出正确和错误的内容。如果你不仔细检查，很容易被它带偏。我踩过的一个坑是：让Agent帮我整理一份技术方案的对比。它输出了一个看起来很专业的对比表格，每个方案都有优缺点分析。我当时觉得挺好，就直接用了。后来才发现，其中两个方案的优缺点它写反了。它并不是故意骗我，而是它在推理的时候搞混了。从那以后，我养成了一个习惯：对于Agent输出的任何事实性内容，尤其是数据、引用、对比结论，我都会抽查验证。抽查的比例不用太高，10%到20%就行，但一定要抽。如果抽查发现错误率超过可接受范围，那就说明这个任务的定义有问题，或者Agent的能力还不足以胜任这个任务。另一个习惯是：让Agent标注它的置信度。在提示词里要求它“对每个结论标注高、中、低置信度，低置信度的结论需要说明原因”。这样你可以快速定位到那些它自己也没把握的地方，重点检查。6. 把“定义”和“停止”变成肌肉记忆6.1 日常训练方法：从简单任务开始刻意练习定义问题和知道何时停下，这两件事都是可以训练的。我的训练方法是从简单任务开始，刻意练习。比如，让Agent帮你查一个数据。这个任务足够简单，但你依然可以练习定义问题：输入来源是什么？输出格式是什么？验收标准是什么？停止条件是什么？查完之后，练习判断停止：它有没有额外输出？有没有超出你的定义？再比如，让Agent帮你改一段文字。练习定义：改什么？不改什么？改成什么样算好？练习停止：改完之后它有没有继续“优化”？有没有改动你没让它改的地方？这些简单任务花不了多少时间，但能帮你养成习惯。等你面对复杂任务的时候，这些习惯就会自动起作用。6.2 团队协作中的经验：怎么让别人也能定义清楚如果你是团队里负责跟Agent打交道的人，你还需要把这种能力传递给其他人。我的经验是，不要指望每个人都能写出好的任务定义。更现实的做法是，提供一个模板，然后要求大家填完模板再提交任务。模板不用太复杂，就是前面说的那七个字段。填完之后，由你来审核一遍，看看有没有歧义、有没有遗漏约束、验收标准是不是可检查。审核的过程本身，就是在帮团队建立对任务定义的共识。另外，我会在团队里维护一个“跑偏案例库”。每次有人遇到Agent跑偏的情况，就把案例记下来：任务定义是什么、跑偏的表现是什么、最后怎么解决的。这个案例库积累到二三十条的时候，团队里大部分人就能避开80%的常见坑了。6.3 一个值得坚持的原则：宁可慢一点，也要定义清楚最后分享一个我自己的原则：宁可花10分钟定义问题，也不要花1小时收拾烂摊子。很多人用Agent的时候，习惯是“先跑起来再说”，觉得定义问题太浪费时间。但实际算下来，定义问题花的时间，远远少于跑偏之后重新跑、重新改、重新检查的时间。而且，定义问题的过程本身，就是在帮你理清思路。很多时候，你以为你想清楚了，但一填模板就发现有很多模糊的地方。这些模糊的地方，如果不提前解决，Agent一定会帮你“解决”——用它的方式，而不是你的方式。所以我现在用Agent，第一步永远是定义问题，第二步永远是设定停止条件。这两步做完，后面的执行反而变得很简单。因为你知道要什么，也知道什么时候该停，剩下的就是让它跑就行了。这个内容后续还可以这样扩展：针对不同类型的任务（比如代码生成、内容创作、数据分析），分别整理出更具体的定义模板和停止条件清单。如果你手头有正在跑的任务，不妨先试着填一遍那个七字段模板，看看能不能把原本模糊的需求写清楚。写不清楚的地方，就是你需要先想清楚的地方。