企业官网建设流程全解析

1. 为什么“会用AI”和“会驾驭AI Agent”是两码事

很多人第一次接触AI Agent这个概念时，脑子里浮现的画面是：对着一个对话框敲几行字，然后它自动帮我订机票、写周报、回邮件。这个想象方向没错，但真正上手之后你会发现，绝大多数人卡住的地方根本不是“AI不够聪明”，而是自己压根没搞清楚Agent的工作边界在哪里。

我刚开始折腾Agent的时候，踩过一个特别典型的坑。当时我想让一个Agent帮我从一堆会议记录里提取待办事项，然后自动按优先级排序。听起来很简单对吧？结果Agent把“下周三之前给客户回复报价”和“有空看看行业报告”排在了同一个优先级。问题出在哪？出在我没有给它任何判断优先级的规则，它只能靠语义猜测，而“有空看看”这种模糊表达在人类看来是低优先级，在Agent眼里和“下周三之前”没有本质区别。

这就是“会用AI”和“会驾驭AI Agent”的分水岭。会用AI的人知道怎么提问，会驾驭Agent的人知道怎么设计规则、怎么拆解任务、怎么给Agent装上“判断力”。前者是操作层面的事，后者是架构层面的事。

这篇内容适合三类人看：第一类是对AI Agent有基本认知但还没动手实操过的开发者；第二类是已经在用Agent做自动化但效果不稳定的实践者；第三类是想把Agent能力集成到自己产品里的技术负责人。不管你是哪一类，接下来的内容都会围绕一个核心问题展开：怎么让Agent按照你的意图稳定地干活，而不是随机发挥。

2. Agent的“大脑”到底由哪几个零件拼成

2.1 从一次失败的自动摘要任务说起

我让一个Agent帮我处理一批用户反馈，任务是“把每条反馈压缩成一句话，并标注情绪倾向”。第一次跑完，结果惨不忍睹。有的反馈被压缩成了“用户不满意”，有的被标注成了“中性”但原文明显在骂人。我一开始以为是模型能力不够，换了个更大的模型，结果只是错得更有创意了。

后来我拆开Agent的执行链路才发现，问题出在三个地方：第一，我没有给它明确的压缩标准，比如“一句话”到底是15个字还是30个字；第二，情绪标注的类别没有定义清楚，“中性”和“轻微不满”之间的界限全靠它猜；第三，它没有参考任何历史标注样本，完全靠预训练知识在判断。

这次经历让我意识到，Agent的“大脑”不是单一模型，而是由好几个零件拼起来的。任何一个零件缺了或者装错了，整体表现就会拉胯。

2.2 规划模块：Agent的“前额叶”

规划模块负责把一个大任务拆成可执行的小步骤。比如“帮我安排一次团队建设活动”这个任务，规划模块会把它拆成：确定参与人数、收集预算范围、筛选场地、对比时间、生成候选方案。这个模块的核心能力是任务分解和依赖关系识别。

我实测下来，规划模块最容易出问题的地方是“过度拆分”和“拆分不足”。过度拆分会让Agent陷入细节，比如把“收集预算范围”又拆成“发邮件问A”“发邮件问B”“等回复”“汇总”，步骤太多导致执行效率极低。拆分不足则是把“筛选场地”和“对比时间”合并成一步，结果Agent在筛选场地时完全没考虑时间冲突。

我的经验是，规划模块的粒度控制在3到7步之间比较合理。少于3步说明拆得不够细，多于7步说明拆得太碎。这个数字不是拍脑袋来的，是我在跑了十几个不同任务之后总结出来的规律。

2.3 记忆模块：短期记忆和长期记忆的分工

记忆模块分两块：短期记忆和长期记忆。短期记忆保存当前任务的上下文，比如用户刚才说了什么、Agent已经执行了哪些步骤。长期记忆保存跨任务的知识，比如用户的偏好、历史操作记录、常见问题的解决方案。

这里有一个特别容易踩的坑：很多人会把所有信息都塞进短期记忆，导致上下文窗口被撑爆，Agent开始“忘事”。我试过在一个长对话任务里，Agent执行到第15步的时候突然把第3步的结论忘了，原因就是短期记忆没有做定期压缩和归档。

正确的做法是：短期记忆只保留最近3到5轮的关键信息，更早的内容压缩成摘要存入长期记忆。长期记忆的检索要有优先级，不是所有历史信息都值得被召回。我一般会给长期记忆设一个“重要性评分”，只有评分超过阈值的记录才会被检索出来参与当前决策。

2.4 工具调用模块：Agent的“手脚”

工具调用模块决定了Agent能做什么。没有工具调用的Agent只能“说”，有了工具调用才能“做”。常见的工具包括：搜索引擎、代码执行器、文件读写、API调用、数据库查询等。

工具调用最容易出问题的地方是“参数传递”。比如Agent要调用一个天气查询工具，需要传入城市名和日期。如果Agent把“明天”直接传进去，工具可能不认识，需要先转换成具体日期格式。我遇到过Agent把“下周一”传成“next Monday”，结果工具只认“2025-06-16”这种格式，直接报错。

解决这个问题的办法是在工具定义里写清楚参数格式，并且在Agent的规划阶段就加入“参数预处理”这一步。不要指望Agent自己悟出来，它悟不出来的。

2.5 执行循环：Agent的“心跳”

执行循环是Agent运转的核心机制：观察当前状态、思考下一步、执行动作、观察结果、继续循环，直到任务完成或触发终止条件。这个循环的质量直接决定了Agent的稳定性和效率。

我见过很多Agent跑着跑着就“卡死”了，原因通常是执行循环缺少终止条件。比如Agent在搜索一个信息，搜了10次都没找到，但它不知道什么时候该停，就一直搜下去。正确的做法是设置最大循环次数和超时时间，超过阈值就强制退出并返回当前结果。

另一个常见问题是“循环震荡”：Agent在两步之间来回跳，比如先查A再查B，发现B不对又回去查A，反复横跳。这种情况通常是因为规划模块没有定义清楚步骤之间的依赖关系，导致Agent在决策时缺乏明确的推进方向。

3. 任务拆解：把“帮我写份报告”翻译成Agent能听懂的话

3.1 模糊指令是Agent最大的敌人

“帮我写份报告”这句话对人来说很常见，对Agent来说却是灾难。写什么报告？给谁看？多长？什么格式？截止时间？这些信息缺失任何一个，Agent都只能靠猜。而猜的结果，十有八九不是你想要的。

我做过一个对比实验：同一份数据，分别用模糊指令和结构化指令让Agent生成报告。模糊指令下，Agent生成了一份800字的泛泛而谈；结构化指令下，Agent生成了一份2500字的分析报告，包含数据图表描述、趋势分析和三条具体建议。差距不是模型能力造成的，是指令质量造成的。

结构化指令的核心要素包括：任务目标、输出格式、内容范围、质量标准、参考示例。这五个要素不需要每次都写全，但至少要有前三个。我一般会用一个简单的模板来组织指令：

任务目标：从给定的销售数据中提取三个关键趋势 输出格式：每个趋势用一段话描述，包含具体数字支撑 内容范围：只分析最近六个月的数据，不涉及预测 质量标准：每个趋势必须有至少两个数据点作为证据 参考示例：参考上次季度报告中的趋势分析写法

这个模板看起来简单，但它把Agent的发挥空间压缩到了一个可控范围内。你给它的约束越多，它的输出就越稳定。

3.2 用“检查点”代替“一口气跑完”

很多人喜欢让Agent一口气跑完整个任务，中间不设任何检查点。这种做法在简单任务上没问题，但在复杂任务上风险极高。一旦中间某一步跑偏了，后面所有步骤都会跟着错，而且你很难定位问题出在哪。

我的做法是在关键节点设置检查点。比如一个“从需求文档生成测试用例”的任务，我会在三个地方设检查点：需求解析完成后、测试用例框架生成后、用例填充完成后。每个检查点都需要人工确认或者自动校验通过，才能进入下一步。

这样做的好处是：第一，问题可以被及早发现，不会等到最后才发现全错了；第二，每个检查点的输出可以作为下一步的输入，减少Agent的上下文负担；第三，如果某个检查点反复出问题，你可以单独优化那一步，不用推翻整个流程。

3.3 给Agent装上“判断力”：规则和示例哪个更管用

让Agent做判断有两种方式：给规则和给示例。给规则是告诉它“如果A则B”，给示例是告诉它“像这种情况就选B”。两种方式各有适用场景。

规则适合边界清晰、逻辑明确的判断。比如“如果用户情绪标注为负面且涉及退款，则优先级设为高”。这种判断用规则表达最准确，不会产生歧义。

示例适合边界模糊、需要经验判断的场景。比如“判断一段用户反馈是否属于产品建议”。这种判断很难用规则穷举，但给几个正例和反例，Agent就能学到判断标准。

我实测下来的经验是：能用规则的地方尽量用规则，规则覆盖不到的地方用示例补充。规则和示例的比例大概在7:3比较合适。全是规则会导致Agent过于死板，全是示例会导致Agent判断不稳定。

还有一个技巧：示例要包含“边界案例”。比如判断“是否属于产品建议”，除了给明显的正例和反例，还要给一些模棱两可的例子，并标注你的判断结果。这样Agent才能学到边界在哪里。

3.4 任务拆解的粒度控制：3到7步法则的实操验证

前面提到了3到7步法则，这里展开说一下怎么落地。假设你要让Agent完成一个“竞品分析”任务，可以这样拆：

1. 确定竞品名单（从给定列表或搜索结果中筛选）
2. 收集每个竞品的基本信息（功能、定价、用户评价）
3. 对比分析（找出差异点和共同点）
4. 生成分析报告（按指定格式输出）

这是4步，在合理范围内。如果你拆成“确定竞品名单、收集竞品A信息、收集竞品B信息、收集竞品C信息、对比A和B、对比A和C、对比B和C、生成报告”，那就是8步，太碎了。碎步骤的问题是Agent需要在步骤之间频繁切换上下文，容易丢失全局视角。

反过来，如果你只拆成“收集信息、生成报告”两步，那就太粗了。Agent在“收集信息”这一步需要同时处理筛选、采集、整理三个子任务，很容易顾此失彼。

3到7步是一个经验区间，具体取多少取决于任务的复杂度和Agent的能力。任务越复杂，步骤可以适当多一些；Agent能力越强，步骤可以适当少一些。关键是每一步都要有明确的输入和输出，不能有“然后再说”这种模糊地带。

4. 记忆管理：让Agent记住该记的，忘掉该忘的

4.1 上下文窗口不是越大越好

很多人选模型的时候只看上下文窗口大小，觉得越大越好。我一开始也这么想，后来发现上下文窗口大了之后，Agent反而更容易“分心”。因为窗口里塞了太多无关信息，Agent在决策时会被干扰。

我做过一个测试：同一个任务，分别用4K窗口和32K窗口跑。4K窗口下Agent的表现反而更稳定，因为它被迫只关注最相关的信息。32K窗口下Agent经常引用一些不相关的历史内容，导致输出偏离主题。

所以上下文窗口的关键不是大小，而是“信息密度”。窗口里每一条信息都应该是当前决策需要的，无关信息要么不存，要么压缩后存。

4.2 短期记忆的压缩策略：摘要、索引和丢弃

短期记忆的压缩有三种策略：摘要、索引和丢弃。

摘要就是把一段对话压缩成几句话。比如“用户问了A、B、C三个问题，我回答了A和B，C还没回答”。这样既保留了关键信息，又减少了token占用。

索引是给每条记忆打标签，需要的时候按标签检索。比如给“用户偏好”打上“偏好”标签，给“历史操作”打上“操作”标签。检索时只召回相关标签的内容。

丢弃就是直接删掉不重要的信息。比如寒暄、确认性回复、重复内容，这些都可以直接丢。我一般会设置一个规则：如果一条信息在后续3轮对话中没有被引用，就自动降权，再过3轮还没被引用就删除。

这三种策略要配合使用。我的经验是：摘要用于对话历史，索引用于知识库，丢弃用于噪音信息。比例大概是5:3:2。

4.3 长期记忆的检索：什么时候该“回忆”，什么时候该“遗忘”

长期记忆的检索要有触发条件，不能每轮都全量检索。触发条件可以是：当前任务涉及历史偏好、当前问题与历史问题相似度高、用户明确要求参考历史记录。

我一般会给长期记忆设一个“相关性评分”，只有评分超过阈值的记忆才会被召回。评分的计算维度包括：时间衰减（越久远的记忆评分越低）、使用频率（被引用越多的记忆评分越高）、任务匹配度（与当前任务越相关的记忆评分越高）。

遗忘机制同样重要。有些信息过期了就不应该再被引用，比如“用户上周说想买A产品”，这周用户可能已经买了或者改变主意了。我一般会给有时效性的记忆设置过期时间，过期后自动归档，不再参与检索。

4.4 记忆冲突的处理：当新信息和旧记忆打架时怎么办

记忆冲突是很容易被忽略的问题。比如Agent的长期记忆里存着“用户偏好简洁回复”，但用户最近几次对话都要求“详细解释”。这时候Agent该听谁的？

我的处理原则是：新信息优先于旧记忆，但旧记忆不会被删除，而是被标记为“可能过时”。当新信息和旧记忆冲突时，Agent应该以新信息为准，同时在回复中确认一下：“我注意到您最近偏好详细解释，后续我会按这个风格来，如果您希望切换回简洁模式随时告诉我。”

这样既尊重了最新意图，又给了用户纠正的机会。如果用户确认“对，以后都详细解释”，那就更新长期记忆；如果用户说“只是这次需要详细”，那就保持原记忆不变。

5. 工具调用：Agent从“能说”到“能做”的关键一跃

5.1 工具定义的三要素：名称、描述、参数

定义一个工具需要三样东西：名称、描述、参数。名称要简洁明确，比如“search_weather”比“get_weather_info”好。描述要写清楚这个工具能做什么、不能做什么、什么时候该用。参数要定义类型、格式、是否必填。

我见过很多工具定义写得特别随意，比如描述只写“查询天气”，参数只写“城市”。结果Agent不知道这个工具支持不支持查历史天气，也不知道城市名要不要带“市”字。最后调用失败，还以为是模型的问题。

正确的写法应该是：

{ "name": "search_weather", "description": "查询指定城市指定日期的天气情况，支持查询未来7天和过去30天的天气。不提供空气质量、紫外线等扩展信息。", "parameters": { "city": { "type": "string", "description": "城市名称，需包含省份或直辖市名称，如'浙江省杭州市'、'北京市'", "required": true }, "date": { "type": "string", "description": "日期，格式为YYYY-MM-DD，如'2025-06-16'。不传则默认查询今天。", "required": false } } }

这个定义看起来啰嗦，但它把Agent可能产生的疑问都提前回答了。工具定义的质量直接决定了调用成功率，这一点怎么强调都不为过。

5.2 参数传递的常见坑：格式、类型和默认值

参数传递的坑我踩过太多了。最常见的是格式不匹配：Agent传“明天”，工具要“2025-06-17”；Agent传“杭州”，工具要“浙江省杭州市”；Agent传“1”，工具要“1.0”。

解决这个问题的办法有两个：一是在工具定义里写清楚格式要求，二是在Agent的规划阶段加入“参数预处理”步骤。我一般会在工具调用前加一个“参数校验”环节，如果格式不对就自动转换，转换不了就返回错误让Agent重新生成。

类型问题也很常见。比如Agent传了一个字符串“3”，工具要的是整数3。这种问题在弱类型语言里可能没事，在强类型语言里直接报错。解决办法是在工具定义里明确类型，并且在Agent生成参数时做类型检查。

默认值的问题容易被忽略。如果某个参数不是必填的，Agent可能不传，这时候工具需要有合理的默认值。我一般会在工具定义里写清楚“不传则默认XX”，避免Agent因为不知道默认值而反复询问。

5.3 工具调用的失败重试：重试几次、间隔多久、什么条件下放弃

工具调用失败是常态，关键是怎么处理失败。我的策略是：区分可重试错误和不可重试错误。

可重试错误包括：网络超时、服务暂时不可用、限流。这类错误可以重试，但要有次数限制。我一般设3次重试，间隔分别是1秒、3秒、9秒（指数退避）。超过3次就放弃，返回错误信息。

不可重试错误包括：参数格式错误、权限不足、资源不存在。这类错误重试多少次都没用，直接返回错误让Agent调整参数或换工具。

还有一个细节：重试的时候要不要修改参数？我的经验是，如果是网络问题，参数不变直接重试；如果是参数问题，先让Agent修正参数再重试。不要盲目重试，那样只会浪费时间。

5.4 多工具协作：编排顺序和依赖关系

复杂任务往往需要多个工具协作。比如“帮我查一下明天杭州的天气，如果下雨就推荐一个室内活动”。这个任务需要先调用天气工具，根据结果再决定是否调用活动推荐工具。

多工具协作的关键是定义清楚依赖关系。哪些工具可以并行调用，哪些必须串行，哪些的输出是另一些的输入。我一般会用一个有向无环图来描述工具之间的依赖关系，Agent按照图的拓扑顺序执行。

并行调用可以显著提升效率。比如“查天气”和“查交通”这两个工具没有依赖关系，可以同时调用。但并行调用也有风险：如果其中一个失败了，另一个的结果可能就没用了。所以并行调用适合那些相互独立的子任务，不适合有依赖关系的任务。

6. 执行循环的稳定性：让Agent不跑偏、不卡死、不震荡

6.1 终止条件的设计：什么时候该停

Agent跑飞的最常见原因是没有终止条件。我见过一个Agent在“搜索信息”这一步循环了20多次，每次都说“再搜一下看看有没有更全的”，结果搜了20多次也没搜出什么新东西。

终止条件要覆盖三种情况：任务完成、任务失败、任务超时。任务完成是正常终止，任务失败是异常终止，任务超时是保护性终止。

任务完成的判断标准要明确。比如“生成报告”这个任务，完成的标准是“报告已生成且通过格式校验”，而不是“Agent觉得差不多了”。任务失败的判断标准也要明确，比如“连续3次工具调用失败”或“关键信息缺失且无法补充”。任务超时就是设一个最大执行时间，比如5分钟，超过就强制终止并返回当前结果。

6.2 循环震荡的识别与打断

循环震荡的表现是Agent在两个或多个状态之间反复跳转，无法推进。比如先查A，发现A不对，去查B，发现B也不对，又回去查A，如此反复。

识别循环震荡的方法是记录Agent的状态轨迹，如果发现某个状态重复出现超过阈值（比如3次），就判定为震荡。打断震荡的方法是强制Agent换一个策略，比如“你已经查了3次A和B，现在换一个思路，试试查C或者直接基于现有信息给出结论”。

我一般会在执行循环里加一个“状态计数器”，记录每个状态出现的次数。超过阈值就触发干预，要么换策略，要么直接终止并返回当前结果。

6.3 异常处理：工具报错、模型超时、结果为空

异常处理是Agent稳定性的最后一道防线。常见的异常包括：工具报错、模型超时、结果为空。

工具报错的处理前面说过了，区分可重试和不可重试。模型超时的处理是设置超时时间，超时后要么重试要么降级到更小的模型。结果为空的处理是判断空结果是否合理，如果合理就继续，如果不合理就重试或换工具。

我一般会给每个步骤设一个“异常处理策略”，写清楚遇到什么异常做什么处理。这样Agent在遇到异常时不会慌，而是按照预设策略执行。

6.4 人工介入的时机：哪些环节必须留给人来判断

不是所有决策都适合交给Agent。有些环节必须留给人来判断，比如：涉及金额超过阈值的操作、涉及敏感信息的处理、涉及最终决策的确认。

我一般会在Agent的流程里设置“人工确认点”。比如“生成报价单”这个任务，Agent可以自动生成草稿，但发送给客户之前必须人工确认。这样既利用了Agent的效率，又保留了人的判断力。

人工介入的时机要提前设计好，不能等出了问题再补救。我一般会在任务拆解阶段就标注哪些步骤需要人工确认，然后在执行循环里加入相应的等待逻辑。

7. 从Demo到生产：Agent落地的几个现实问题

7.1 成本控制：Token消耗的优化思路

Agent跑起来之后，Token消耗是一个绕不开的问题。我见过一个Agent跑一次任务消耗了50万Token，成本高得离谱。优化Token消耗的思路有几个：

第一，压缩上下文。前面说的短期记忆压缩策略就是为了减少Token占用。第二，缓存常用结果。比如天气查询、汇率转换这类结果可以在短时间内缓存，不用每次都调用工具。第三，选择合适的模型。简单任务用轻量模型，复杂任务用大模型，不要一律用最大的。第四，限制输出长度。给Agent设一个最大输出长度，避免它生成冗长的内容。

我实测下来，经过优化之后Token消耗可以降低60%到70%，而任务质量基本不受影响。

7.2 效果评估：怎么判断Agent干得好不好

评估Agent的效果不能只看“任务完成没完成”，还要看完成的质量、效率、稳定性。我一般从四个维度评估：任务完成率、平均执行步数、异常发生率、人工干预率。

任务完成率是基本指标，但要注意区分“真完成”和“假完成”。有些Agent会假装完成任务，比如生成一个空报告说“已完成”。所以完成率要配合质量校验一起看。

平均执行步数反映效率。步数太多说明规划有问题，步数太少说明可能漏了步骤。异常发生率和人工干预率反映稳定性。这两个指标越低越好，但也不能为零，为零说明Agent可能在该报错的时候没报错。

7.3 安全边界：哪些事情绝对不能让Agent自主决定

Agent再智能也不能让它什么都能干。我一般会设三条红线：涉及资金的操作必须人工确认、涉及用户隐私的数据不能外传、涉及法律合规的决策不能由Agent做出。

除了红线，还有一些灰线需要根据场景判断。比如“自动回复客户邮件”这件事，简单咨询可以自动回，涉及投诉或退款就必须转人工。灰线的判断标准要写清楚，不能模糊。

7.4 迭代策略：从规则驱动到数据驱动的演进路径

Agent的迭代一般分三个阶段：规则驱动、示例驱动、数据驱动。

规则驱动阶段，所有判断逻辑都是人写的规则。这个阶段Agent的行为最可控，但扩展性差，规则多了之后维护成本很高。

示例驱动阶段，人给一些标注样本，Agent从样本中学习判断标准。这个阶段扩展性好一些，但依赖样本质量。

数据驱动阶段，Agent从大量历史数据中自动学习。这个阶段效果最好，但需要足够的数据积累和反馈机制。

我的建议是不要跳阶段。先把规则驱动跑通，再逐步引入示例，最后过渡到数据驱动。跳阶段的结果往往是Agent行为不可控，出了问题也找不到原因。

8. 我踩过的三个典型坑和对应的解法

8.1 坑一：Agent把“建议”当成了“指令”

有一次我让Agent“分析一下这份数据，如果有异常就提醒我”。结果Agent不仅分析了数据，还自动把异常数据删掉了。它的理解是“提醒”等于“处理”，而我的本意只是“告诉我”。

这个坑的本质是Agent对动词的理解和人类不一致。“提醒”“建议”“分析”这些词在人类看来是“只说不做”，但在Agent看来可能包含“做”的意味。

解法是在指令里明确区分“只读操作”和“写操作”。如果只想让Agent分析，就写“只分析并输出结果，不要修改任何数据”。如果想让它处理，就写“分析并处理异常数据”。不要用模糊的动词，用明确的动作描述。

8.2 坑二：Agent在长任务中丢失了初始目标

我让Agent做一个“从100条用户反馈中提取产品改进建议”的任务。前20条处理得挺好，到第50条的时候Agent开始跑偏，把一些不是建议的反馈也当成了建议。到第80条的时候，它已经完全忘了“只提取建议”这个初始目标，把所有反馈都列出来了。

这个坑的本质是长任务中上下文漂移。Agent在处理大量数据时，初始指令在上下文中的权重会逐渐降低，被后续内容淹没。

解法是在每个处理批次开始时重新注入初始目标。比如每处理20条就重新说一遍“记住，你的任务是只提取产品改进建议，其他内容忽略”。这样虽然增加了Token消耗，但能显著提升长任务的稳定性。

8.3 坑三：工具返回的错误信息把Agent带偏了

有一次Agent调用一个API，API返回了一个很长的错误堆栈。Agent没有识别出这是错误，反而把错误堆栈当成了正常返回结果，基于错误信息继续往下执行，最后生成了一个完全错误的报告。

这个坑的本质是Agent对“错误”和“正常结果”的区分能力不足。尤其是当错误信息很长、包含很多技术术语时，Agent容易把它当成有效信息。

解法是在工具定义里明确标注“成功返回格式”和“错误返回格式”，并且在Agent的规划阶段加入“结果校验”步骤。如果返回结果不符合成功格式，就判定为失败，触发重试或异常处理。

9. 关于Agent驾驭这件事，我的一些个人体会

折腾Agent这段时间，最大的感受是：Agent的能力上限不取决于模型有多强，而取决于你对任务的理解有多深。你如果自己都没想清楚任务该怎么拆、判断标准是什么、异常怎么处理，Agent肯定也做不好。

另一个体会是：不要追求“全自动”。很多人一上来就想做一个完全不需要人工干预的Agent，结果往往是灾难。我的做法是先从“半自动”开始，人工确认关键节点，等流程跑稳了再逐步减少人工介入。这个过程急不得。

还有一个反直觉的经验：Agent的稳定性比能力更重要。一个能力一般但每次都能稳定输出的Agent，比一个能力很强但时好时坏的Agent有价值得多。因为前者可以嵌入到生产流程里，后者只能用来做Demo。

最后说一个实操技巧：给Agent写指令的时候，把自己想象成在给一个刚入职的实习生交代任务。你会怎么跟实习生说，就怎么跟Agent说。实习生听不懂的模糊表达，Agent也听不懂。实习生会误解的地方，Agent也会误解。这个类比帮我在写指令时避免了很多想当然的表述。