写在前面Agent 不是“更聪明的聊天框”很多人第一次听 Agent会觉得它很像升级版 ChatGPT你给它一个目标 它自己拆任务 自己调用工具 自己观察结果 自己继续执行 最后把事情做完。这个想法很吸引人。因为它听起来像是从“回答问题”进化到了“完成任务”。但真正做过 Agent 的人都知道它最麻烦的地方不是不会动而是动起来以后不一定停得住也不一定动得对。一个普通聊天模型答错了你最多得到一段错误文本。一个 Agent 答错了可能会反复调用工具 不断烧 API 改错文件 删错数据 发错请求 把错误结果当成事实继续推理。所以 Agent 的核心问题不是“能不能自动”而是“自动到什么边界为止”。Agent 到底多了什么普通大模型聊天大概是用户输入 - 模型生成回答Agent 多了一个循环用户目标 - 模型思考 - 选择工具 - 执行工具 - 观察结果 - 再思考 - 再选择工具...这就像从“顾问”变成“实习生”。顾问只给建议实习生会动手。动手就会带来工程问题它能用哪些工具 每个工具权限多大 失败了怎么处理 循环几次必须停 成本超过多少要停 危险操作谁来确认 结果怎么验证。如果这些问题没设计清楚Agent 很容易失控。失控类型一循环停不下来最常见的失控就是循环。比如你让 Agent 修一个测试失败。它运行测试看到失败改代码再运行测试。结果还是失败。于是它继续改继续跑。表面上它很努力实际上可能陷入了没有理解根因 每次只修表面错误 一个修改引入另一个错误 测试环境本身有问题 工具输出被误读 目标条件不明确。如果没有循环上限它会一直消耗时间和 token。更糟的是Agent 有时会“自我安慰”。工具失败了它会换个说法继续命令没跑通它会假设跑通文件没找到它会猜路径。这不是模型坏而是它在缺少可靠终止条件。怎么防循环最基础的做法是给循环加硬限制最多执行 N 步 最多调用 N 次工具 最多花费 N 元 最多运行 N 分钟 连续同类失败 N 次就停。但只有硬限制还不够。你还需要让 Agent 会判断“没有进展”。比如连续三次测试失败如果失败信息完全一样就不应该继续乱改。它应该停下来总结我尝试了什么 失败信息是什么 为什么怀疑当前方向不对 需要用户确认什么。一个好 Agent 不只是会继续也要会停。失控类型二成本不透明Agent 比普通聊天更容易烧钱。因为它不是一次回答而是多轮思考一次 调用工具一次 读文件一次 再思考 再调用 再总结。如果接的是云端模型每一步都是 token。如果工具里还有搜索、数据库、第三方 API成本会继续叠加。很多团队做 Agent 原型时一开始觉得效果不错等到真实用户多起来才发现账单很吓人。成本失控通常来自没有预算上限 上下文越堆越长 重复读取同一批资料 失败后无脑重试 工具返回太大 没有缓存 没有便宜模型和强模型分层。怎么控成本Agent 成本控制要前置设计。可以从这几个点开始控制点做法步数每个任务设最大步数token上下文定期压缩工具限制高成本工具调用次数模型简单判断用小模型关键步骤用强模型缓存相同检索和文件读取不要重复做日志记录每一步成本和原因人审超预算前请求确认最重要的是把预算当成产品功能而不是后台指标。用户应该知道这个 Agent 大概会跑多久 可能调用哪些工具 什么时候需要我确认 失败时会不会继续烧钱。失控类型三错误工具调用Agent 真正危险的地方是工具调用。如果模型只能输出文字错误还比较可控。如果它能调用工具错误就可能变成真实动作。比如把测试数据库当成生产数据库 把删除命令用在错误目录 把邮件发给错误对象 把搜索结果里的广告当成官方文档 把敏感文件上传到外部服务。工具越强风险越大。所以 Agent 设计里有一句很重要的话不要给模型超过任务所需的权限。它只需要读文件就不要给写权限。它只需要查库就不要给删库权限。它只需要生成草稿就不要让它直接发送。工具权限怎么设计可以按风险分层。工具类型风险建议读文件低到中限制目录和文件类型搜索网页中要求来源校验写文件中到高diff 后确认执行命令高沙箱、白名单、超时发邮件/发帖高必须人工确认数据库写入高事务、回滚、审批删除操作极高默认禁止或强确认工具不是越多越好。很多 Agent 失败就是因为工具太多、描述太模糊、权限太大。一个工具应该有清楚的边界它能做什么 不能做什么 输入格式是什么 失败会返回什么 是否有副作用 是否需要确认。失控类型四错误结果继续放大Agent 有一个很隐蔽的问题它会把上一步的错误当成下一步的事实。比如搜索工具返回了一篇过期文章模型基于它写方案。代码测试其实没跑成功模型却以为通过了。RAG 召回错了片段模型继续总结出错误结论。这叫错误放大。普通聊天里错误停在一段回答里。Agent 循环里错误会进入状态影响后续所有步骤。解决办法是给关键节点加验证命令是否真的成功 文件是否真的存在 测试是否真的通过 搜索来源是否可靠 数据库写入是否符合预期 最终输出是否满足用户目标。不要让模型自己宣布成功。让系统用可检查的信号判断成功。好 Agent 应该怎么设计一个靠谱 Agent通常不是“无限自主”而是“有限自主”。它应该有这些边界明确目标 有限工具 最小权限 步骤上限 成本预算 失败停机 关键操作确认 结果可验证 完整日志。这听起来没有“全自动 Agent”那么酷但更能上线。产品上也可以分级模式适合场景只读建议分析、总结、规划草稿模式写邮件、生成代码、生成 SQL半自动修改文件但需确认自动执行低风险、可回滚任务高权限执行强审计和强审批场景不要一上来就追求最后一级。一个简单的 Agent 安全清单如果你正在做 Agent可以先问这些问题它最多能跑几步 它最多能花多少钱 它能访问哪些文件 它能不能执行删除操作 它能不能向外部发送数据 它调用工具失败后怎么处理 它怎么知道任务完成了 它什么时候必须问用户 每一步有没有日志 出了错能不能回滚如果这些问题答不上来就不要急着给它更大权限。Agent 按自主程度分类不是所有 Agent 都应该完全自动。可以按自主程度分成 5 级。等级名称特点风险L0 聊天助手只回答不调用工具最安全低L1 只读 Agent读文件、查资料、总结可观察低到中L2 草稿 Agent生成代码、SQL、邮件草稿需要人确认中L3 半自动 Agent能改文件、跑测试、提交草稿需要权限控制中到高L4 自动执行 Agent能调用外部系统并产生副作用必须强审计高L5 高权限 Agent能部署、删数据、发消息、改生产默认不建议极高很多失控事故本质是任务只需要 L1却给了 L4 权限。比如“帮我分析日志”只需要读取日志。如果你同时给它执行命令、修改配置、重启服务的权限就把风险放大了。设计 Agent 时先问完成这个任务最低需要几级自主只给最低权限。Agent 循环也分类型Agent 不是只会一种循环。不同循环处理方式不同。1. 探索循环它不断读文件、搜资料、查接口想弄清楚情况。风险是上下文越来越长最后抓不住重点。应对限制搜索范围 要求阶段性总结 超过一定步数必须提出计划。2. 修复循环它反复改代码、跑测试、再改代码。风险是越改越乱。应对同一错误连续出现就停止 每轮只允许小改 必须保留 diff 失败后先分析根因。3. 工具重试循环工具调用失败后它不断换参数重试。风险是打爆 API、触发限流、产生副作用。应对指数退避 最多重试次数 明确哪些错误不可重试 高成本工具重试前确认。4. 目标漂移循环它一开始要解决 A跑着跑着开始解决 B。比如用户让它“修登录按钮样式”它最后开始重构整个权限系统。应对每步检查是否仍服务原目标 禁止无关重构 计划变更需要确认。工具按副作用分类Agent 工具设计里最重要的不是工具多不多而是副作用多大。工具类别例子默认策略只读工具读文件、查日志、搜索文档可以开放但要限范围可逆写入新建草稿、写临时文件允许但要可回滚不可逆写入删除文件、发消息、改数据库默认确认外部公开动作发帖、发邮件、开工单必须人工确认生产操作部署、扩容、删库强审批和审计很多工具表面看只是“调用 API”但副作用不同。查询订单和取消订单都是 API 调用风险完全不是一个级别。设计 Agent 的防护栏防护栏不是一句“请谨慎操作”。真正的防护栏要落到系统里。1. 输入防护识别危险请求 识别越权意图 识别 prompt injection 限制文件路径和 URL。2. 工具防护参数 schema 校验 工具白名单 权限分级 危险工具确认 dry-run 模式。3. 循环防护最大步数 最大成本 最大时间 连续失败停止 目标偏离停止。4. 输出防护结果格式校验 敏感信息过滤 引用来源检查 最终执行前确认。5. 事后防护完整日志 可回滚记录 失败报告 人工复盘 黑名单规则更新。什么任务适合 AgentAgent 适合的任务通常有几个特点步骤明确 工具结果可验证 失败可回滚 成本可控 风险不高 人可以中途接管。比如读项目并生成启动说明 根据测试失败定位可能文件 整理多份文档的差异 批量生成草稿 查日志并总结异常。不适合的任务没有明确完成条件 高风险生产操作 需要复杂伦理或法律判断 失败不可回滚 工具权限过大但验证信号弱。Agent 的好场景不是“让它什么都干”而是把可检查、可分步、可恢复的工作交给它。最终结论Agent 容易失控不是因为 Agent 这个概念错了而是因为它把“语言生成”变成了“带副作用的行动”。行动就必须有边界。循环、成本、错误工具调用是 Agent 落地最常见的三个坑循环没有进展还继续跑 成本多轮调用不断叠加 工具模型选错或用错工具造成真实后果。我的建议是先做只读 Agent 再做草稿 Agent 再做需要确认的半自动 Agent 最后才考虑低风险自动执行。真正可靠的 Agent不是看起来最自由的那个而是知道什么时候该停、该问、该验证的那个。