1. 从会聊天到能办事为什么大模型必须走Agent这条路过去一年里我见过太多团队把大模型接进系统后发现它只能做高级版搜索话痨式问答。用户问一句它答一段看着热闹实际上和业务系统之间隔着一道墙——它不会主动去查库存不会替你提交工单更不会在一个流程跑偏时自己纠错。问题出在哪出在我们把大模型当成了终点而不是引擎。真正要让大模型产生业务价值必须给它装上手脚让它能调用工具、能对接系统、能在无人盯着的情况下把一个多步骤任务跑完。这条路业内通常叫Agent化改造。这篇文章不聊概念不抄论文就讲我在实际项目中怎么把一个纯对话式大模型一步步改造成能干活、能对接、能自动跑任务的Agent系统。整个过程中踩过的坑、绕过的弯、最后沉淀下来的可复用方案都摊开来讲。先说清楚一个判断大模型本身只是大脑Agent体系才是那个让大脑指挥手脚的神经系统。你要做插件化改造本质上是给大脑接出无数根神经让它能触达外部工具和系统你要做系统对接本质上是把这些神经接到真实业务的血肉里你要做自动化任务本质上是让整套神经反射不再需要人类逐级下发指令。这条改造路径适合谁参考如果你正在做大模型应用落地手头有对话机器人、有企业内部系统、有不少重复性人工操作想自动化那么这篇文章里的思路、代码结构和排坑经验应该能帮你省下至少两到三周的试错时间。2. 整体架构设计Agent不是单点技术而是一套工程体系2.1 先想清楚你要的Agent到底长什么样很多团队一上来就问我用什么Agent框架我通常会反问你的Agent需要干几步活每步活需要碰几个系统这两个问题的答案直接决定你是用轻量编排、上重型框架还是干脆自己写个状态机。以我这次的实践项目为例业务目标是把一个智能运维助手从纯问答升级为可自动执行运维任务的工作流。具体场景包括收到告警后自动拉取日志、分析异常根因、查询变更记录、给出处置建议甚至在授权范围内自动执行回滚脚本。整个链路涉及日志系统、监控系统、CMDB配置库、工单系统四个外部依赖总共五到六个步骤的编排。这个复杂度决定了我不可能只用调一次模型Function Call就搞定。必须有一个明确的Agent运行时负责管理任务状态、调度工具调用、处理模型返回、在出错时决定是重试还是上报人工。2.2 核心模块拆解五层结构各司其职我最终采用的架构分为五层每层职责单一互相之间通过接口通信。这套结构的好处是后续无论是换底层模型、加新工具还是改任务编排逻辑都只需要动对应的一层不用推倒重来。接入层统一封装多种模型来源本地部署的开源模型、云端API模型对外暴露一致的思考调用接口。上层完全不关心底层跑的是Qwen还是GPT。规划层负责任务拆解。收到用户目标后把大任务拆成有序的原子步骤决定每一步用哪个工具、需要什么参数。工具层所有插件化能力的注册中心。每个工具本质是一个函数带清晰的输入输出Schema供模型按需选择调用。执行层真正的Agent运行时。它负责维护会话上下文、追踪任务状态、发起工具调用、处理工具返回结果并判断任务是继续、终止还是需要人工介入。对接层与外部系统监控、日志、工单、数据库等通信的适配器集合。每个适配器解决鉴权、协议转换、数据格式归一化等脏活累活。这五层听起来抽象打个比方你就懂了。接入层是大脑不同区域的输入神经规划层是大脑前额叶负责想清楚先迈左脚还是右脚工具层是手边能抓到的各种工具执行层是小脑和脊髓反射弧保证动作连贯不出错对接层是手脚上的传感器和肌肉接头得能跟外部世界的螺丝、扳手、零件严丝合缝地咬合。2.3 为什么不用重型框架而是自研轻量编排技术选型时我先后评估了LangChain、LlamaIndex这类主流框架也看了几款新兴的Agent专用框架。说实话这些框架的组件丰富度确实高文档也漂亮但对于我这个场景来说问题也很明显一是版本迭代太快社区里教程和实际API经常对不上团队维护成本高二是框架抽象层次太深真到排查问题时得翻好几层源码才能定位到是自己传参错了还是框架自身有bug三是自带的工具调用逻辑偏通用面对企业内部系统那堆不规范但必须兼容的接口时往往得绕过框架自己写适配。最终我选择了一条轻量框架自定义编排的路线只借用LangChain的工具调用抽象和模型接入能力任务编排和状态管理全部自己写。这样做的底气在于Agent的核心逻辑其实不复杂——就是一个循环:模型决定调用哪个工具 - 执行工具 - 把结果喂回模型 - 模型决定下一步。把这个循环控制在自己手里出任何问题都能快速定位不会被框架的黑盒逻辑绑架。关于技术选型我的建议是如果你的任务链路固定、步骤不超过三到五步、外部系统接口规范直接用成熟框架没问题但如果你要面对长期演进的复杂业务流程自研一个几十行核心代码的编排器长期来看反而是更省心的选择。3. 插件化改造实操让模型学会用工具的完整闭环3.1 工具定义为模型写一份看得懂的函数说明书插件化改造的第一步不是写代码而是定义工具的说明书——也就是Function Schema。模型不像人它没法看源码猜函数怎么用你必须在Schema里把函数名、功能描述、参数含义、参数类型、必填项、返回值结构写得清清楚楚。这里有个经验之谈工具描述一定要写什么时候该用这个工具而不是只写这个工具是干什么的。就拿日志查询工具举例如果你只写查询日志模型在用户问刚才系统是不是报错了时可能根本想不到要调用它但如果你写成查询指定时间段内指定服务的日志适用于用户反馈异常、监控告警、发布变更后排查问题时使用模型就会更精准地触发调用。我整理了一个标准工具Schema模板每次新增插件都照着填name工具名小写下划线风格全局唯一description功能说明 典型使用场景50字以上越具体越好parametersJSON Schema格式的参数定义每个参数都注明类型、是否必填、默认值、取值范围returns明确的返回值结构说明方便模型理解返回内容timeout超时阈值防止工具长时间不返回卡死整个任务error_codes可能抛出的异常码和含义让模型知道工具调用失败后该怎么处理参数命名也讲究。别用什么a、b这类缩写也别用data这种过于笼统的名字。我见过模型把完全无关的字段塞进工具调用的情况十有八九是参数名描述有歧义。像start_time就写清楚是查询开始时间ISO8601格式如2024-06-01T00:00:00Z模型基本不会搞错。3.2 工具注册与动态加载新插件三分钟上线插件化改造的核心诉求之一就是新工具能快速接入老功能不受影响。所以我落地了一套基于约定优于配置的工具注册机制。每个插件是一个独立的Python包目录结构固定plugins/ query_log/ __init__.py manifest.yaml handler.py query_cmdb/ __init__.py manifest.yaml handler.pymanifest.yaml里声明工具名、版本、依赖的外部系统、需要的环境变量handler.py里实现真正的业务逻辑。系统启动时Agent Runtime扫描plugins目录加载所有manifest.yaml校验Schema合法性把可调用函数注册进工具列表然后连同Schema一起注入到模型API的请求里。这套机制带来的直接收益是后续新增一个工具团队里任何一位后端开发只要照葫芦画瓢写个handler再也不用动Agent主流程的代码。整个过程从改代码到联调上线快的话一小时就能完成。我想强调的是工具层的核心设计目标是让加工具变成一件像填表一样简单的事让工具质量成为团队唯一需要关注的重点。如果加个工具还要东改西改主流程说明你的插件化抽象还没做到位。3.3 Function Call的正确姿势别把参数拼接当回事工具定义好了模型怎么真正调用这块我强烈建议别自己写Prompt硬套输出格式而是用模型自带的Function Call / Tool Call能力。目前的模型API都支持在请求里显式声明可用工具。当你声明了工具模型在需要时不会直接输出普通文本而是结构化的工具调用指令——包括工具名和提前算好的参数JSON。代码收到这个结构化输出后去执行对应的函数即可。一个标准的调用循环长这样def run_agent_with_tools(user_message, available_tools): messages [{role: system, content: SYSTEM_PROMPT}, {role: user, content: user_message}] for step in range(MAX_STEPS): response client.chat.completions.create( modelMODEL_NAME, messagesmessages, toolsavailable_tools, tool_choiceauto ) # 终止条件模型正常回复文本不再调用工具 if not response.choices[0].message.tool_calls: return response.choices[0].message.content # 执行工具调用 for tool_call in response.choices[0].message.tool_calls: tool_result execute_tool(tool_call.function.name, json.loads(tool_call.function.arguments)) messages.append({ role: assistant, tool_calls: [tool_call.model_dump()], content: None }) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) })这里有一个很多初学Agent开发的人容易踩的坑拿到模型的工具调用指令后直接返回执行结果给用户就完事了。正确的做法是执行完工具一定要把结果再喂回给模型让它结合工具返回的真实数据生成一份完整的答复。否则模型连日志里到底有没有报错都不知道怎么给你有依据的结论循环里一定要设置最大步数上限防止模型陷入无限调用工具的死循环。我见过有些场景下模型反复调用同一个查询工具几十次费用蹭蹭涨任务还没个结论。MAX_STEPS我一般设8到10够绝大多数业务链路用。3.4 工具调用结果太长怎么办压缩与表达实际项目中遇到的另一个真实问题是模型调工具返回了一坨几十KB的日志JSON直接塞回上下文里既浪费Token又干扰模型判断。此时需要对工具返回结果做预处理。我的策略是三级处理第一级工具handler内部自己做字段裁剪和摘要返回的JSON只保留关键字段第二级如果单条结果仍然很大我会在返回前用规则或小模型做一次信息压缩提取关键时间点、错误码、关键字第三级设置返回内容的上限超过就截断并标注结果过长已截断如需完整内容请调用查询详情工具。这套处理逻辑效果立竿见影同样一个查日志工具处理前每次调用要消耗约3000 Token处理后压缩到500 Token以内模型的分析准确率反而更高了——因为干净的数据里找不到噪声它就很难被无关信息带偏。4. 系统对接实战把Agent连进真实的业务系统4.1 对接策略不是让系统适应模型而是让适配器消化差异把Agent接到生产系统时最容易翻车的不是模型不会问而是企业内部系统压根不按常理出牌。有只支持SOAP协议的古老接口有返回XML却不告诉你格式的有鉴权方式还是用户名密码拼在URL里的有数据量一大就超时的——这些现实问题靠Agent本身解决不了必须在对接层处理。我的做法是在对接层为每个系统写一个适配器对上层暴露统一接口内部搞定鉴权、协议转换、数据归一化、重试、超时处理等杂活。这样Agent代码永远只操作Python dict不用管对方到底是JSON还是XML是HTTP还是WebService。对接层设计的核心原则是**内部统一、外部适配**。理想情况下Agent调任何一个外部系统走的是同一套接口语义入参是结构化的请求对象出参是结构化的响应对象错误统一用异常抛出由执行层统一捕获处理。底层谁是谁Agent不知道也不关心。4.2 鉴权与安全别把系统钥匙模型手里对接系统绕不开鉴权。这块我的态度非常明确模型只能通过工具间接访问外部系统工具内部完成鉴权模型拿不到任何敏感凭据。具体落地方式是所有敏感凭证API Key、密码、Token统一存在环境变量或专门的密钥管理服务里工具函数执行时从配置中心读取用完即弃。模型调用工具时只需要传业务参数比如查什么服务、什么时间段完全不知道用什么密钥去查的。有一个安全细节容易被忽略不要把工具的返回结果里夹带的敏感信息完整展示给用户或模型。比如CMDB查询接口会返回服务器IP、账号等内部信息如果全量塞给模型模型可能把它原封不动说出来。我的方案是在适配器层做数据脱敏规则配置——该打码的打码该摘除的摘除只有真正需要的信息才让模型看到。4.3 HTTP回调型系统对接异步任务怎么等结果多数外部系统是同步接口请求-响应一步到位。但有些业务系统是异步设计你提交一个任务它先返回一个task_id然后你轮询另一个接口才能知道任务是否完成、结果是什么。Agent对接这类系统时如果按同步思路写必然卡死。标准解法是把异步等待封装成一个工具内部的循环提交任务 - 拿到task_id - 每5秒轮询一次 - 超时则抛出异常告知模型任务处理中请稍后再查。这里有一个决策点值得展开到底要不要把轮询封装在工具内部我测试过两种思路。第一种工具只负责提交任务并返回task_id让Agent自行决定等多久、查几次。听起来灵活实际很糟糕——模型对时间流逝没有感知你问它等一分钟后再查它真的就傻傻地返回已等待但实际只过了两秒。第二种就是我最终采用的把异步等待逻辑写死在工具里模型只需要发起一次调用工具内部同步等到结果再返回。虽然单次调用耗时变长但模型的认知负担大幅降低任务成功率明显提升。我的结论是在Agent的工具设计中凡是涉及时间等待的逻辑都尽量封装在工具内部别指望模型有耐心。4.4 数据格式归一化让模型看到说人话的结果外部系统的返回数据五花八门。监控系统返回的是嵌套十几层的JSON日志系统返回的是纯文本工单系统返回的是XML。如果把这些原始返回直接丢给Agent模型在理解上会有很大负担也更容易出现幻觉。为此我建了一套数据归一化规范要求所有适配器返回给Agent的数据必须符合这个格式所有字段名统一为snake_case时间字段统一为ISO8601字符串数值字段带单位如duration_seconds而不是duration状态字段枚举统一映射如对方返回的1/2/3统一转成success/pending/failed长文本字段先做摘要或截断空值统一返回null不返回None或空字符串这套规范看起来简单实际救了不少次场。有一次联动排查的Agent频繁答非所问最终定位原因某个系统的状态字段返回英文大写SUCCESS另一个返回数字0模型在不同调用之间被搞晕了不知道哪个才算真成功。统一枚举之后这类问题直接消失。5. 自动化任务全流程实现一个真实场景的完整体验5.1 场景定义告警处置自动化的完整链路理论讲再多不如跑通一个真实场景。这次我选的实验场景是告警自动诊断与处置流程图我就不画了直接给你看任务链路收到一条告警消息例如某服务响应时间超过阈值Agent调用监控系统适配器查询该服务当前状态指标Agent调用日志系统适配器查询告警时间窗前后的异常日志Agent调用CMDB适配器查询该服务最近是否有变更记录以及对应的负责人信息Agent结合前三步结果进行根因分析如果分析结论指向明确的已知故障模式且变更记录显示刚发布过新版本Agent在获得授权后执行回滚动作最终生成一份处置报告内容包括告警概况、根因判断、执行动作、验证结果、后续建议并通过工单系统自动提交这个场景涵盖了一个Agent系统几乎所有经典环节工具调用、系统对接、多步编排、条件分支、授权控制、结果汇报。跑通它基本就打通了Agent化的任督二脉。5.2 任务拆解与编排让模型想清楚再做任务有了Agent怎么知道先做哪一步再做哪一步这里我采用的策略是规划先行、逐步执行。收到告警后Agent先不急着调工具而是把整体思考过程写到内部状态里输出一份执行计划类似{ goal: 诊断api-gateway服务响应时间告警并给出处置建议, steps: [ {step: 1, action: query_monitor, reason: 先确认服务当前状态是否仍异常}, {step: 2, action: query_log, reason: 拉取异常日志判断错误类型}, {step: 3, action: query_cmdb, reason: 检查是否有变更导致异常}, {step: 4, action: decide_and_execute, reason: 根据证据链执行或建议处置} ] }有人可能问既然Agent会自己规划为什么还要预先搭好流程框架我的经验是预置关键流程规则不是限制模型能力而是防止它天马行空跑偏。比如在这个场景里我预设了一条硬性规则必须先查CMDB确认变更后才能决定是否执行回滚动作。如果没有这个约束模型可能在日志还没查完时就直接建议回滚这在生产环境是不可接受的。当然编排层也不应该把每一步都写死。我给Agent留出的自主空间是查询范围和时间窗口可以自己判断根因分析完全由模型基于证据链推理处置建议可以自主拟定但涉及变更回滚这个高危动作必须经过授权校验。5.3 关键函数实现与调用链整个流程的核心是让Agent循环执行调用规划模块 - 决定下一个动作 - 调用对应工具 - 结果回填 - 进入下一轮。我按约定好的五层结构把代码按模块拆开之后整个主流程可以精简成一个可读性很强的调度函数。关于这个问题我的建议是先跑通单个工具确认模型真的会用再串链路。很多人一上来就写完整编排结果分不清是工具的问题还是流程的问题。从小处着手一点点增加复杂度排查效率最高。5.4 授权控制高危操作必须踩刹车Agent执行自动化任务时最常见的安全争议就是机器能不能直接做变更。我的答案是能但必须分级授权。我落地了一套三级授权机制绿区自动执行无副作用或影响面小的操作比如查询指标、查询日志、生成分析报告。Agent可以完全自主执行无需人工干预。黄区自动执行事后通知有一定影响、但可快速回退的操作比如重启某个非核心服务、下发配置到预发环境。Agent可执行但执行后必须通知相关负责人。红区需人工审批影响面大或不可逆的操作比如生产环境回滚、数据清理、批量操作。Agent只能生成操作方案并提交审批待人工确认后才真正执行。实现红区授权时我用了一个非常朴素但有效的机制Agent内部持有一个操作许可表执行任何动作前先查这张表。如果是红区操作Agent不直接执行工具而是调用工单系统的创建审批请求工具把完整的操作方案写清楚推送给审批人。审批人通过后审批系统回调Agent执行接口Agent才真正动手。这套机制上线后才算真正解决了自动化效率和安全可控之间的核心矛盾。业务方不再担心Agent乱动生产Agent也不用为了一个简单查询层层等人审批。5.5 执行效果与性能实测整个流程跑通后我做了一轮详细的效果测试。测试方式是模拟30条不同类型的告警消息Agent全自动跑完诊断处置建议链路统计成功率、耗时和需要人工介入的比例。实测结果总结如下指标结果诊断准确率判断根因正确86.7%全自动完成率无需人工介入80.0%平均总耗时从告警到产出报告约75秒单次任务模型调用次数平均4.6次主要失败原因个别系统接口超时 / 日志数据缺失80%的全自动完成率意味着30条告警里24条Agent自己就能搞定剩下6条需要人工兜底。说实话这个比例已经超出了我最初的预期。对比人工处理的平均耗时——以往一条复杂告警从收到、查日志、翻CMDB、写结论至少15到20分钟——Agent把时间压缩到了75秒效率提升了一个数量级。也正是80%由Agent处理20%由人工兜底这种协作模式让我更加确信Agent化的核心价值不是彻底取代人而是把人类从重复、低价值的操作里解放出来让人的精力集中在真正需要判断力的那20%上。6. 常见问题与排查技巧实录6.1 模型死活不调用工具怎么办这是Agent开发史上最常见的疑难杂症没有之一。模型就是在那里唠唠叨叨分析得头头是道最后给你一段纯文本结论就是不调你注册的工具。我排查这个问题时按以下顺序逐一检查工具描述是否以人话写清楚了使用场景很多工具描述写得像接口文档模型根本理解不了什么时候该用。请求里是否真的传了tools参数有一次我犯低级错误为了调试临时注掉了tools结果模型当然不知道有工具可用。模型对工具名的理解是否一致如果工具名为get_service_cpu_usage但模型在回答里写的是查询CPU使用率而不是调用工具说明描述和模型习惯用语不匹配。是否给了工具调用示例少量few-shot示例一两句对话示范对低版本模型尤其管用。一个异常好用的调优技巧是在系统Prompt里加一句铁的规则分析过程可以思考但最终必须调用工具获取真实数据后才能下结论禁止凭空猜测。这句规则虽然朴素但实测能显著提升模型调用工具的主动性。6.2 模型调用工具时参数乱传另一种翻车现场工具倒是调了但传的参数完全不对。你让它查2024年6月1日到6月3日的日志它给你传个{start_time: now}之类的玩意。这类问题的根源大多出在工具参数定义上。你要是把时间参数定义成start_date: string模型当然不知道格式是ISO8601还是时间戳。正确做法是在参数描述里给足约束信息甚至支持让模型先把用户的话里提到的相对时间如最近一小时换算成绝对时间当前时间减3600秒。我最终在参数Schema里把每个字段的描述都写成具体的、可校验的格式例如{ name: query_log, parameters: { type: object, properties: { service_name: { type: string, description: 必填服务名如 api-gateway、user-service }, start_time: { type: string, description: 必填查询开始时间ISO8601格式如2024-06-01T00:00:00Z }, end_time: { type: string, description: 必填查询结束时间ISO8601格式如2024-06-01T00:00:00Z }, keyword: { type: string, description: 可选关键字过滤 } }, required: [service_name, start_time, end_time] } }写清楚之后参数错传率直线下降。如果你发现模型频繁传错某个参数基本可以断定是这个参数的定义对模型来说不够明确别急着怪模型笨。6.3 工具调用结果格式变化导致解析失败外部系统接口升级返回字段名改了或者本来该返回JSON的接口突然返回了一个带前缀的字符串这类隐形炸弹在Agent系统里风险比传统系统更大——因为传统系统是代码调用类型不匹配会立刻报错而Agent系统里模型会将错就错拿看似相似实则错误的字段继续分析产出看似合理实则荒谬的结论。经验教训是在适配器层除了数据类型校验我还添加了一套轻量级的响应内容合理性巡检。比如某个查指标的接口返回的CPU使用率值必须在0到100之间如果巡检发现超出范围默认返回一个特殊异常码响应数据校验失败Agent收到后就不会硬着头皮编一个说法而是如实告诉用户该接口返回异常建议人工检查。在Agent系统里让模型知道我不知道比让模型不知道我知道重要一万倍。数据源出问题时宁可让Agent承认自己查不到也不能让它用过期或错误的数据生成一本正经的结论。6.4 多轮对话中上下文丢失导致的任务漂移长任务执行过程中Agent时常出现一种半路失忆的症状——任务执行到第三步时突然忘记最初的目标是什么开始回答起工具返回里看似相关但偏离主线的问题。这背后的原因在于多轮工具调用会产生大量中间结果这些中间结果会迅速挤占上下文窗口。模型在有限的上下文里更多地看见了最近的工具返回反而把最初用户的核心诉求给挤出了注意力范围。这里我分享一个亲测有效的方法每轮工具调用结束后把自己的计划便签重新注入上下文。具体来说每一轮对话中都在系统消息里保留一段结构化文本当前任务目标诊断api-gateway服务响应时间告警原因 已完成步骤已确认当前服务状态异常已获取异常日志发现大量TimeoutException 下一步计划查询CMDB变更记录确认是否存在变更关联这段计划便签一注入模型就像被拉回了正轨任务漂移率大幅下降。我建议在做Agent系统时把这个计划维护当作一把必修课别心疼那几个Token它带来的稳定性提升绝对值回票价。6.5 接口链路过长导致Agent等死有些场景下单次工具调用需要很长时间——比如大数据量查询或异步任务轮询。Agent在等结果时如果超时设置不合理很容易在中间环节默默挂掉既不报错也不继续用户看到的就是没有响应。我的处理经验是为每个工具单独配置超时时间让普通查询类工具在10秒内返回结果而将涉及大数据聚合、异步处理的工具超时放宽到60秒或更长。同时在工具描述里明确提示模型本工具调用可能需要约20秒请耐心等待这样模型在等待期间不会因为长时间没有新消息而误判。更重要的一点是在Agent运行层面加一个全局总时长限制比如单次任务最长允许执行180秒。一旦超时Agent主动终止当前任务并生成一条任务超时请缩小时间范围后重试的明确报错。在链路自动化的世界里超时中断加提示信息永远比无限等待然后再告诉你我什么也没干要体面得多。7. 踩坑总结与Agent化改造的真心建议整个项目落地之后如果只能给出一条一句话总结那就是Agent化改造的难点不在模型而在工程。模型选型、Prompt调优这些固然重要但真正决定一个Agent业务系统能否扛住真实压力、长期稳定运行的是那套围绕模型搭建的工程体系——工具怎么定义、系统怎么对接、状态怎么管理、异常怎么兜底、安全怎么控制。给即将动手的同行几句掏心窝的话。第一请一定从一个小而实的场景切入不要一开始就想搞一个无所不能的通用Agent。告警诊断、工单处理、报表生成都是好场景但做一个能自动写年终总结的Agent大概率只会收获一堆又长又空的废文。第二把工具质量当成产品来做一个工具描述模糊、参数定义不清的Agent层无论底层模型多好都是事倍功半的结局。第三一定要设计好兜底逻辑Agent最多能在你的授权边界内自动跑到什么程度边界之外必须做到能停下来、能上报、能让人接手这东西在架构设计第一天就得想明白。我个人在多次踩坑后最大的变化是不再迷信某个神奇的Agent框架也不再试图用一条巨型Prompt让模型拥有擎天柱般的本领。我更愿意花时间把系统切成小块一小块管工具的清晰描述一小块管异步任务的耐心等待一小块管结果的安全返回再把它们用最简单的循环串起来。正是这种笨功夫让大模型这个聪明的大脑真正在一个个朴素的业务场景里踏实干活。