最近在做一个自动化文档处理的内部小项目发现一个很有意思的转变。以前用大模型是“我问一句它答一句”现在把模型接进一个带工具调用的循环里它开始自己决定下一步调用哪个函数、拿到结果后再判断下一步走哪条路。这种变化不是模型变聪明了那么简单而是整套使用方式从“伸手要答案”变成了“布置一个目标”。所以当“AI不再听命令了它开始自己干活”这句话出现在眼前时我第一反应是这说的不是某个新工具而是 AI Agent 这个概念终于从演示走向了工程实践。但真正落地时你会发现AI 自己干活并不是魔法而是一套需要目标拆解、工具调用、状态管理、失败恢复、权限控制共同支撑的工程系统。这篇文章想聊的就是这件事。1. 先搞清楚“自己干活”到底指什么1.1 Chatbot 是在回答Agent 是在执行很多人会把“能对话的 AI”和“会干活的 AI”搞混。你打开一个聊天窗口让它生成一段文案、写一段代码、解释一段报错它都能做到。但这是“回答”不是“干活”。干活意味着你给一个目标它自己规划路径、调用外部工具、检查中间结果、修正下一步动作最后交付一个结果。比如“帮我把这个 GitHub 仓库的最近 10 条 commit 整理成一份周报并按模块分类再生成一个 Markdown 文件”Chatbot 只能给你一段建议或者一段示例文本剩下的复制粘贴、获取数据、生成文件都要你自己做。而 Agent 会尝试通过工具调用去拉取 commit 列表、调用模型总结、写文件最后给你输出一个真实存在的文件。核心差异不在模型能力而在系统边界。Chatbot 的边界是“对话”Agent 的边界是“任务”。这是“自己干活”的第一层含义。1.2 核心变化从“每一步都告诉它”到“我只给目标”过去用自动化脚本是人把每一步逻辑写死。比如用 Python 拉取数据、写文件流程是固定的。现在用 Agent人不需要把每一步都写死只需要描述目标、提供工具清单让模型自己决定调用顺序。这听起来很像“把控制权交给 AI”但工程上更准确的表述是把任务拆解从“写代码时确定”变成了“运行时动态决定”。举个例子同样是生成周报传统脚本先 git log再分词再套模板每一步都是 if-else。Agent模型先判断“哦我需要获取 commit 列表”于是调用git_log工具拿到列表后又判断“内容太长了我需要先过滤掉 merge commit”于是再调用git_parse最后判断“生成 Markdown”然后调用write_file。这个流程不是预先写死的而是模型根据工具返回结果动态生成的。这才叫“自己干活”。不过要注意这里的“自己”不是完全自主。Agent 的每一步行动仍然受系统设计约束能调用哪些工具、最多走多少步、哪些操作需要人工确认这些都是我们预先定义的。所以更准确地说它是在我们划定的轨道里自主决策。2. 为什么是现在大模型和工程底座同时到位2.1 模型能力从“能对话”到“能遵循指令并调用工具”两三年前想让模型稳定地给出一个“我要调用某个工具及参数”的 JSON都不是一件容易事。你构想的 Agent 循环早就存在但模型经常理解错工具参数、忘记上下文、在复杂任务里跑偏。现在的情况好了一些但也不是完全成熟。这里有两个关键能力指令遵循能力模型能更准确地按照系统提示输出结构化指令比如{tool: get_commits, params: {repo: foo}}。工具调用能力平台层面把“模型决定调工具”和“执行工具返回结果”做成了标准协议比如 Function Calling、Tool Use开发者不用自己拼 prompt 解析文本模型直接返回结构化调用请求。这两个能力加在一起Agent 循环才变得可工程化。不是说模型已经完美而是“容错成本”降到了可以接受的范围内。2.2 工程底座任务编排、日志、消息队列逐步补齐模型能力只是其中一半。另一个被很多人忽略的推动力是工程基础设施的成熟。一个真正“自己干活”的 Agent背后需要像任务调度系统一样的循环控制什么时候调用大模型什么时候调工具工具超时怎么办模型返回格式不对怎么办任务失败要不要重试每一步的状态记录在哪里如何让用户看到中间进度任务中止逻辑是什么。这些不是模型解决的问题而是工程问题。以前这些都要从零搭很繁琐。现在不少框架和平台把循环控制、工具注册、日志 trace、人工审核节点做成了现成模块开发者只需要聚焦业务本身。这也是为什么最近一年 AI Agent 开发突然从“玩具”变成了“可落地项目”的原因之一。但我的经验是不要因为框架多就急着套用。先把最小循环跑通再逐步替换组件远比一开始引入一个复杂编排系统要稳。3. 从零搭一个“自己干活”的 Agent最小可运行示例3.1 场景定义自动生成项目周报我们用最经典的场景来拆解让 Agent 自动获取仓库 commit生成周报写入本地文件。这个场景足够小但覆盖了 Agent 的核心问题感知外部数据、模型决策、调用工具、检查结果、生成最终输出。首先需要定义两个工具get_commits(since_date, repo_path)拉取指定日期之后的提交列表。write_report(content, file_path)把内容写入 Markdown 文件。Agent 要做的就是根据用户目标自己决定先调用哪个、怎么处理中间结果。从代码结构看核心是一个循环def agent_loop(user_goal, tools, max_steps10): messages [{role: user, content: user_goal}] for step in range(max_steps): response model_decision(messages, tools) # 情况一模型认为任务已完成返回最终答案 if response.is_final_answer: return response.final_content # 情况二模型决定调用某个工具 tool_result execute_tool(response.tool_name, response.tool_arguments) messages.append({ role: tool, tool_call_id: response.tool_call_id, content: tool_result }) raise Exception(f超过最大步数任务未完成)这个循环并不复杂但它背后藏着几个关键设计决策。3.2 工具注册告诉模型“你能用什么”模型并不知道系统里有哪些函数你需要通过工具描述把能力暴露给它。比如[ { name: get_commits, description: 获取指定 Git 仓库某日期之后的提交列表, parameters: { type: object, properties: { since_date: {type: string, description: 起始日期YYYY-MM-DD}, repo_path: {type: string, description: 本地仓库路径} }, required: [since_date, repo_path] } }, { name: write_report, description: 把周报内容写入 Markdown 文件, parameters: { type: object, properties: { content: {type: string, description: 完整 Markdown 内容}, file_path: {type: string, description: 输出文件路径} }, required: [content, file_path] } } ]工具描述不要太含糊也不要太啰嗦。模型会根据这段描述判断“我现在应该调哪个工具、传什么参数”。如果描述不清晰Agent 很容易在工具选择上绕圈。3.3 关键参数最大步数、超时、输出校验最小循环跑通容易但真正要稳定运行需要给 Agent 设边界。最大步数防止模型在循环里空转。通常是 5 到 15 步具体取决于任务复杂度。超过步数就终止并在日志里记录。单次工具超时比如 git 命令可能因为仓库过大卡住要给每个工具单独设置超时。输出校验模型返回的 JSON 不总是合法代码里要做异常捕获解析失败时可以重试一次或者把错误信息返回给模型让它自行修正。注意不要一上来就把步数设到 50 或 100先设 10 步以内确保能稳定完成后再逐步放宽。这个最小示例跑通以后才算真正理解了“AI 自己干活”的技术底层它是一个由模型决策驱动的执行循环而不是一个单纯的对话服务。4. 别高兴太早真正能稳定跑起来的工程细节4.1 工具边界Agent 能调什么不能调什么要写清楚这是我在实际项目里踩过的坑。如果工具列表里只有get_commits和write_report那 Agent 最多也就是读 Git 和写文件风险可控。但一旦加上“发送邮件”“执行 shell 命令”“删除文件”“推送远端仓库”这类高风险工具就必须在系统层面对 Agent 做权限收敛。具体做法是对工具做分级只读工具默认允许写操作需要确认删除/推送类操作直接禁用或要求人工审批。在工具描述里明确约束比如“只有用户明确要求时才能调用删除功能”。在代码层面强制校验工具参数不能完全依赖模型自律。Agent 以为自己很聪明但真正决定风险下限的是工具暴露面。工具给得越宽意外越多。4.2 失败重试不是所有错误都该重试很多 Agent 框架里都有自动重试机制但错误类型不一样对策也不一样。常见的失败分三类临时失败网络超时、API 限流、Git 仓库锁占用等待几秒后重试通常有效。输入错误模型传错了参数比如日期格式不对、文件路径不存在。此时盲目重试只会得到同样的错误应该把报错信息返回给模型让它自己修正。不可恢复错误比如目标仓库不存在、工具权限不足。这种情况应该直接终止任务并告诉用户原因。最简单的排查顺序是先看环境再看输入再看模型决策。如果模型连续三次选择了同一个错误工具大概率不是偶然而是工具描述有歧义。4.3 日志回放每一步的思考、调用、结果都要留痕“AI 自己干活”最怕什么不是它干不好而是你不知道它为什么干不好。所以 Agent 的日志要比普通脚本详细得多。每一步至少记录当前是第几步。模型本轮说什么也可以记录思考过程如果平台支持。模型调用了哪个工具传了什么参数。工具返回了什么内容耗时多久。模型根据工具结果做了什么判断。最终终止原因是什么。这套日志就是 Agent 的“黑匣子”。遇到问题先回放不是靠猜。5. 什么场景适合让 Agent“自己干活”什么场景最好别5.1 适合的场景流程固定但步骤多结果可验证从我的经验看合适的 Agent 任务通常有三个特点有明确目标比如“把 A 目录下所有 PDF 转成 Markdown”“从数据库导出最近 30 天订单并生成汇总表”。步骤虽然多但路径相对清晰不需要太多天马行空的创造更多是重复性操作。结果可验证生成的文件能不能打开、数据有没有缺失、格式对不对都可以用程序检查。这类任务交给 Agent 之后省下的不是思考时间而是“人来回切换系统”的成本。真正缩短的是流程链路不是模型输出。5.2 不适合的场景不可逆、高风险、价值观判断凡是“错一次代价很高”的任务我都建议保守处理。举几个例子自动删除生产环境数据。自动对外发送不可撤回的消息。自动修改核心系统配置。自动生成法律、医疗、金融领域的正式建议。这些场景不是模型能力不够而是错误容忍度太低。Agent 即使只错一次代价也可能非常大。安全起见可以让 Agent 负责“准备工作”和“草稿生成”最终决策和关键操作仍然由人完成。5.3 一个通用判断清单可以拿下面这份清单快速判断一个任务适不适合 Agent判断维度适合不适合目标是否明确是一条话能说清楚模糊、需要反复澄清流程是否稳定固定但有分支每次都不一样完全无规律结果是否可验证可以用程序检查只能靠人凭经验判断风险高低低错了改一下就行高错了代价大是否需要人类价值观基本不需要需要大量主观判断如果命中“不适合”列超过两条建议不要上 Agent至少不要全自动。6. 从我自己的经验看先跑通、再优化、最后才谈自动化6.1 阶段一单任务跑通别先谈复杂编排第一次做 Agent千万别直接设计一个多智能体协作系统。先把“一个模型 少量工具 一个循环”做到稳定。比如上面那个周报生成示例先手动跑 5 次确认每次都能正确生成文件。这期间不用追求速度、不用追求复杂功能重点是把异常处理、日志、边界参数打磨好。单次跑通只能说明流程没有断。真正的问题会在重复执行和多场景覆盖时浮出来。6.2 阶段二加批量和并发观察限流与资源占用单任务稳定后下一个挑战是批量和并发。假设你要同时为 10 个仓库生成周报就要考虑并发调用大模型 API 时是否触发限流。本地命令执行是否占用过多 CPU、内存。输出目录是否冲突文件会不会被覆盖。如果中途某几个任务失败是整体重跑还是只重跑失败项。这时候再回头看“AI 自己干活”你会发现干活的不只是 AI还有一堆工程细节。批处理和并发控制就是最常见的第一道坎。6.3 阶段三加入监控、权限、审核才能长期用长期可用的 Agent 系统和一次性脚本之间的区别在于可观测、可干预、可审计。可观测有指标看板能看到 Agent 今天的成功率、平均步数、平均耗时。可干预任务执行中支持人工暂停、修改参数、驳回某一步操作。可审计所有执行记录都能回溯出了问题能定位到具体某一步。这三个能力不是一开始就要做全但在 Agent 进入真实业务之前至少要有一个能让现场人员介入的“急停按钮”。实际落地时建议每周复盘一次 Agent 日志从失败样本里反推工具描述是否需要优化、步数上限是否合理、哪些工具权限太宽。这不是一次性的调参而是持续迭代。7. 最后AI 自己干活但先得知道哪条路不能省回到一开始那个判断AI 不再听命令了它开始自己干活。这话没错但“自己干活”不是模型单独完成的而是模型、工具、工程边界、日志审计共同完成的一件事。模型负责的是“决策”真正对结果负责的还是人。我们给 Agent 规划目标、划定工具边界、定义验证方式、设置失败兜底它才能在一个可控范围内“自己干活”。所以如果你正准备做一个 Agent 项目我的建议是先从最小流程开始不急着给工具开权限不盲目追求多智能体、复杂规划。把单任务跑通把日志埋好把失败路径想清楚再把任务范围一点一点扩大。这条路看着慢但到了生产环境会发现它其实是最快的路。
