★ FEATURED ARTICLE 我们团队最近半年一直在搞一套 Agent 系统从最开始拿着大模型 API 写几个 ReAct 示例的玩具原型到后来真刀真枪接进业务线当生产工具用中间踩了不少坑也沉淀出一些自己的方法论。很多朋友问 Agent 到底怎么搭网上资料大多是概念科普或者碎片化 demo真正讲清楚从零怎么想、怎么设计、怎么落地的不多。这篇文章我就把这半年折腾下来的思路、理想形态和一次真实落地过程完整拆开讲希望能给正在搞 Agent 或者准备入坑的人一点参考。1. 内容整体设计与思路拆解1.1 到底什么算一个合格的 Agent 系统在聊搭建方法之前得先把什么是 Agent这件事掰扯清楚。现在市面上对 Agent 的定义非常混乱有些人把拿模型 API 套了个 system prompt 就叫 Agent有些人把工作流编排也叫 Agent还有一些人干脆把能调工具的都统称 Agent。我个人比较认同的一个判断标准是Agent 的核心在于自主决策 多步规划它不是一个单次请求返回结果的接口而是能够根据目标自己拆解步骤、自己调用工具获取信息、根据执行结果调整下一步动作的程序实体。举个例子如果你想做一个自动写行业调研报告的系统简单封装的大模型调用是用户说帮我看看新能源行业模型直接吐出一篇泛泛而谈的文章没有数据支撑也没有最新动态。而一个合格的 Agent 系统应该是先拆解任务收集行业动态、找龙头企业数据、分析政策变化、生成报告大纲然后逐步执行调用搜索工具、爬取指定网站、读取结构化数据、将结果写入报告模板每一步执行完检查结果是否符合预期不符合就重新尝试或者换一个方案。这个区别非常关键。它不是 1 和 0 的区别而是一个有没有闭环的区别。没有闭环的只是一个 API 封装有闭环的才算是一个系统。我有一个比较朴素的判断方法如果这个程序跑起来之后中间任何一步都不需要人来干预且能在面对失败时自己调整策略那它就是一个 Agent。反过来如果中途断了就要人工介入、换个输入就要改代码那离系统还有距离。1.2 从业务问题反推Agent 不是银弹很多人一听 Agent 就觉得啥都能做这个认知误区得第一时间纠正。Agent 适合解决的是目标明确、步骤可拆解、工具可调用的问题而不是随便聊聊的问题。我见过一些团队拿 Agent 做开放域的聊天机器人动不动就烧掉十几万的模型调用费用效果还很一般。为什么因为开放域对话本质上是生成不需要复杂的工具调用Agent 的规划能力在这里完全发挥不出来反而因为多了规划层导致响应变慢、成本变高。在做整体设计之前一定要先回答几个业务层面的问题用户的核心诉求是什么是检索信息、操作流程、生成分析还是对话陪伴这个任务是否需要多步决策如果单次 prompt 就能解决根本不需要 Agent。可用的工具集有哪些工具的质量决定了 Agent 能力的上限Agent 本身只是调度器。出错成本有多高如果 Agent 答错会造成严重后果就必须严格控制自主性加审核环节。我自己的经验是技术选型永远排在业务问题拆解之后。你先把任务链条想清楚哪个环节需要规划、哪个环节需要工具、哪个环节需要人工兜底然后再去选框架、选模型、设计 prompt。顺序反了后面全是坑。1.3 三个关键设计原则在我做过的几次 Agent 落地中有三条原则是反复验证过的几乎适用于所有场景。第一最小自主性原则。永远不要一上来就让 Agent 全自主执行所有步骤而是从每一步都确认开始逐步放权。这有点像是带新人先让他做完每一步都跟你汇报你认为没问题了再让他并行处理多个步骤。Agent 的自主性越高对底层模型质量和工具稳定性的要求也越高这两个东西跟不上全自主就是灾难。第二工具优先模型兜底。Agent 的聪明程度其实取决于它能调用什么工具。模型负责的是决定调用哪个工具、怎么传参、怎么解读结果工具负责把事真正做成。你能给 Agent 接上精确的数据库查询接口它就不需要靠记忆回答数据类问题你能给它接上内部 API它就能操作真实业务。所以设计 Agent 的时候一半以上的精力都应该花在如何把现有能力封装成干净的、可被模型调用的工具上。第三失败是常态设计时就把失败当成一等公民。Agent 在真实环境中的成功率不可能 100%甚至 70% 就算不错了。关键在于失败之后怎么办是重试、换方案还是上报人工这个决策逻辑必须提前设计好不能等跑挂了再想。2. 核心细节解析与实操要点理想形态长什么样2.1 一个完整 Agent 系统的四层结构基于我做过的项目和看过的一些优秀开源实现我总结出一个比较理想的 Agent 系统分层结构。它不一定适合所有场景但可以作为设计时的参考坐标系。自下而上分别是第一层是工具层。包括搜索 API、数据库查询接口、内部业务系统 API、代码执行环境、文件读写模块等。这一层的核心要求是每个工具的输入输出都有明确的 Schema 定义并且有足够的容错能力。模型调用工具时经常会出现参数幻觉比如把一个字符串传给了要求 int 的字段工具层必须能给出清晰的报错信息方便模型自己纠正。第二层是记忆层。包括短期记忆当前任务上下文和长期记忆跨会话的历史信息、用户偏好、领域知识。短期记忆一般直接用上下文窗口管理但要注意控制 token 消耗长期记忆则需要向量数据库或者结构化存储在需要的时候检索相关片段灌回上下文。第三层是规划层。这是 Agent 区别于普通程序的核心。常见实现方式有ReAct 模式的循环推理思考-行动-观察、任务分解把目标拆成子任务再逐个解决、以及带反思机制的规划执行完一轮之后总结经验下一轮避免同样的错误。规划层的设计决定了 Agent 的智商上限。第四层是执行与反馈层。负责把规划层产出的动作序列真正跑起来收集执行结果并反馈给规划层。同时执行过程中产生的异常与部分成功信息需要被结构化记录不能简单丢给模型一段报错文本就完事。我实际搭建的时候是把这四层对应到代码模块里的tools/ 放工具封装memory/ 放记忆管理planner/ 放规划逻辑executor/ 放执行器。模块边界清晰后面调试和维护都会轻松很多。2.2 规划层的三种主流模式对比规划层是大家最关心的也是命名最混乱的部分。市面上讲 Agent 规划基本跑不出三种模式我直接对比一下。模式核心理念适用场景优点缺点ReAct 循环思考-行动-观察交替进行直到完成任务工具调用为主的任务比如问答、检索简单直接、容易实现、对模型要求相对低步骤多时容易跑偏缺乏全局规划Plan-and-Execute先整体拆分任务成子任务列表再逐步执行复杂多步骤任务比如报告生成、数据分析有全局视野步骤可控方便人工介入初期计划可能不准确执行后需动态调整反思与自我修正每轮执行后总结错误经验用于后续步骤高质量要求场景比如代码生成、写作能持续改进最终效果上限高额外消耗 token延迟增加我自己做生产系统的时候最常用的是 ReAct 和 Plan-and-Execute 的混合模式先让模型基于整体目标做一个粗粒度的步骤规划然后在执行每一步的时候用 ReAct 循环来动态决策具体动作。这种混合设计兼顾了全局稳定性和局部灵活性。还有一点想特别提醒规划不是越细越好。步骤拆得太细会导致每一小步都要调用一次模型延迟叠加、成本翻倍而且每一步都有出错概率链条越长整体失败率越高。我见过有人把一个简单问答拆成 8 个步骤结果 6 个步骤都在做无用功。合理的做法是能一步做完的不拆两步必须拆开控制的才拆。2.3 记忆管理理想形态中的隐形难点记忆是 Agent 系统里最容易被低估的部分。很多初版 demo 不做记忆模型每次都是全新开始在单轮任务里问题不大但只要涉及多轮交互或者需要复用历史信息系统智商立刻归零。短期记忆的痛点在于上下文管理。每一步工具调用的输入输出都会占用 token如果全塞进上下文几轮之后就把窗口撑爆了。我常用的手段包括用摘要压缩历史对话、只保留与当前目标相关的关键片段、把工具返回的原始大文本存到外部存储而不是塞回上下文。长期记忆则需要解决存什么和怎么取两个问题。存什么不是所有交互都值得存只存那些对未来有价值的信息比如用户偏好、项目关键约束、已经验证过的结论。怎么取靠向量检索相关度但相关度不等于有用度所以通常还需要一个 rerank 环节或者基于规则的过滤。我在实际项目里是把长期记忆按不同类型分表存储的比如用户画像表、项目事实表、历史决策表查询的时候按类型分别检索再合并。记忆这一块做得好不好直接影响用户对 Agent 的聪明感。有时候你觉得某个 Agent 很懂你其实不是它推理能力多强而是它的记忆层把你之前的需求和偏好都调出来了。2.4 工具调用理想 Agent 的能力边界我始终认为Agent 的能力边界就是它工具集的边界。模型再聪明没有好工具调用也只能凭空想象工具足够强即使模型弱一些也能干出漂亮活。工具设计的核心要求是单一职责 参数明确。单一职责很好理解一个工具就做一件事不要搞一个大而全的函数。参数明确意味着参数名要让模型一看就懂、参数类型要严格校验、必填可选要划分清楚。我在实践中还发现一个很有用的小技巧在工具描述里不只是写这个工具是干嘛的还要写清楚什么情况下用这个工具、什么情况下不要用模型看到这种提示之后工具选择的准确率会提升不少。工具层的容错设计也很重要。工具调用过程中网络超时、API 限流、数据格式异常都是常态。我一般会在工具封装里做三层防护第一层是参数合法性校验第二层是异常捕获并转换成模型能看懂的友好报错第三层是超时控制和重试机制。有了这三层模型在大多数异常情况下都能自行恢复不需要人工介入。另外要提醒的是给 Agent 接工具的时候一定要有权限和审计的意识。Agent 操作的每个动作都要留有日志尤其是涉及写操作、删除操作、费用操作的场景必须有审批或限制阀值。这不仅是安全考虑也是生产系统的基本素养。3. 实操过程与核心环节实现一次真实落地记录3.1 项目背景我们到底要解决什么问题说一个我最近完整落地的项目以下细节做了脱敏处理不影响参考价值。某团队内部沉淀了大量技术文档、项目方案和复盘记录分散在多个内部系统和文档平台里。团队成员每天要花大量时间翻文档找资料很多同事反馈知道有这个东西但找不到在哪。老板希望做一个内部知识问答助手让员工用自然语言提问系统自动从各个来源找到答案并给出引用出处。听起来是个标准的 RAG 场景但实际需求比标准 RAG 复杂得多文档分布在多个数据源有的是结构化表格有的是非结构化 Markdown还有的是扫描件转出来的文本。很多问题的答案不在单篇文档里而是需要跨文档拼接。有些问题需要调用内部 API 获取实时数据比如最近某项目的进度到哪了。用户期望答案有权威出处不能只给一段不知来源的总结。所以这个项目本质上是一个需要检索-分析-调用-回答链路的 Agent 系统而不是单纯向量检索加生成。3.2 技术选型框架、模型、存储的取舍技术选型我分三块来说Agent 框架、模型、存储。Agent 框架我选择了 Python 生态里的 LangChain。当时也对比了几种方案直接用原生代码编排 LLM 调用、用 LangChain、用更重量级的框架。最终选 LangChain 的原因很实际它对各种工具和模型提供商的适配最全社区案例最多出问题容易搜到答案。虽然 LangChain 的抽象层级多、调试起来偶尔让人抓狂但对比自己从零写一套工具调用和记忆管理模块的开发成本还是划算的。后来为了保持代码可控核心的规划逻辑没有被框架牵着鼻子走而是用框架做工具调用和数据连接的翻译层规划控制流放在自己的业务代码里。模型方面我用了强模型做规划 快模型做执行的组合策略。规划模型负责理解用户意图、拆解任务、决定下一步动作需要强的推理能力执行模型负责总结单个文档内容、生成回答文本需要速度快、成本低。两个模型拆分之后整体延迟降了约 30%成本降了一半以上。存储方面文档向量化后放进向量数据库同时保留了文档本身的关系型元数据标题、作者、更新时间、来源系统方便后续做过滤和权限控制。当时选向量库的时候比较看重两点一是检索性能要能撑住百万级向量二是要方便做元数据过滤。可以先用开源方案验证后续数据量大了再迁移到云服务成本和灵活性都兼顾了。3.3 核心流程实现从提问到回答的全链路我直接贴一下这个 Agent 系统的核心流程实现用的是伪代码加注释的方式方便理解每一步在做什么。# 主流程用户提问 - Agent 规划 - 工具执行 - 生成回答 def ask_agent(question: str, user_info: dict) - str: # 1. 记忆召回先从长期记忆里捞相关信息 memory_context memory_retrieve(question, user_info) # 2. 规划让规划模型产出执行计划 plan planner_agent( questionquestion, memory_contextmemory_context, available_toolsget_tool_schemas() ) # 3. 按计划执行每个步骤都走 ReAct 循环 collected_evidence [] for step in plan.steps: result execute_step_with_react(step) collected_evidence.append(result) # 如果某一步失败让规划模型决定是重试还是调整计划 if not result.success: plan planner_agent( questionquestion, previous_stepscollected_evidence, errorresult.error, moderepair ) # 4. 生成最终回答要求带上引用来源 answer generator_agent( questionquestion, evidencecollected_evidence, regulations[答案必须基于证据不可臆造, 每个关键结论标注来源索引] ) return answer这个流程看起来简单核心逻辑其实都在函数内部。我重点讲两个关键模块的实现细节。第一个是execute_step_with_react它本质上是思考 - 调用工具 - 观察结果的循环伪代码如下def execute_step_with_react(step) - StepResult: max_iterations 5 current_input step.task for i in range(max_iterations): # 让模型决定下一步动作 action model_act( taskcurrent_input, toolsstep.available_tools, past_attemptsstep.history ) if action.type call_tool: tool_result call_tool(action.tool_name, action.parameters) step.history.append((action, tool_result)) if tool_result.is_error: # 把错误信息反馈给模型让它自己修正 current_input f你刚才的调用出错了请根据错误修正。错误信息: {tool_result.error} else: # 工具调用成功看看是否足以完成当前步骤 current_input f工具已返回结果如果足够解决问题就结束本步骤否则继续调用其他工具。结果: {tool_result.content} elif action.type finish: return StepResult(successTrue, outputaction.final_answer, historystep.history) return StepResult(successFalse, error超过最大循环次数, historystep.history)第二个是工具层封装。这里我特别想讲一下如何让工具对模型友好。光写一个函数签名是不够的模型真的会看不懂。我最终采用的是比较啰嗦但很有效的工具描述方式每个工具的 schema 里除了参数定义还写了详细的注意事项和使用场景。比如文档搜索工具的描述是这么写的工具名称: search_internal_docs 用途: 在内部文档库中搜索与关键词相关的文档返回文档标题、摘要、来源链接 使用场景: - 用户提问涉及具体项目、技术方案、历史决策时使用 - 需要给回答补充内部资料引用时必用 - 不确定问题答案时优先使用此工具收集事实 不要使用此工具的情况: - 用户只是闲聊 - 问题答案需要实时业务数据这种场景应该用 query_business_data 参数: - keyword: 字符串必填搜索关键词建议提取用户问题中的核心名词 - doc_type: 字符串选填限定文档类型可选值 [project, tech, decision] - limit: 整数选填返回条数默认 5最大 20把这套描述喂给模型之后工具选择的准确率提升非常明显。下图是我记录的一组对比脱敏后的统计口径相同版本工具选择准确率回答引用覆盖率用户满意率只有函数签名76.2%61.5%68.3%完整工具描述92.8%88.4%86.7%同样的模型只是换了一套工具描述效果天差地别。所以你在做 Agent 的时候如果感觉模型老是选错工具先别急着换大模型把工具定义好好打磨一遍收益往往比换模型更大。3.4 记忆与上下文的工程细节这个系统上线之初有一个很头疼的问题用户多轮提问之后Agent 会把前面的上下文全部保留导致 token 消耗越来越大响应越来越慢。后来我做了一套两级记忆管理方案。第一级是会话摘要。每当历史对话超过一定长度就调用成本较低的模型把前面的关键信息压缩成一段摘要替换掉原始对话。摘要里保留的信息包括用户已经问过的问题、已有的结论、用户提到的偏好、尚未完成的遗留事项。第二级是事实缓存。如果 Agent 在某个步骤中通过工具查询到了一个关键事实比如某项目当前处于联调阶段这个事实会被单独提取出来和问题一起放入短期记忆结构体后续步骤不需要重新查询。class SessionMemory: def __init__(self, max_short_term_tokens: int 4000): self.short_term [] # 最近的对话和工具结果 self.summary # 历史压缩摘要 self.max_short_term_tokens max_short_term_tokens def add_exchange(self, user_question, assistant_parts): self.short_term.append({ q: user_question, a: assistant_parts, key_facts: extract_key_facts(assistant_parts) }) self._maybe_compress() def _maybe_compress(self): total_tokens estimate_tokens(self.short_term) if total_tokens self.max_short_term_tokens: old_exchanges self.short_term[:-2] # 保留最近两轮 compressed summarize_exchange(old_exchanges) self.summary merge_summary(self.summary, compressed) self.short_term self.short_term[-2:] def build_context(self) - str: context f历史摘要{self.summary}\n for item in self.short_term: context f用户{item[q]}\n助手{item[a]}\n return context这套方案上线之后长会话的 token 消耗减少了大概 40%而且没出现失忆问题。如果对话特别长可以再加一个定时任务把旧的会话摘要归档到长期记忆库进一步释放空间。3.5 工具链集成与异常处理实录讲几个真实环境里遇到的工具链异常这些是文档上不会写但极容易踩的坑。第一个是内部系统的 API 限流。Agent 一旦跑起来调用频率比人肉点击高得多。某内部系统的 API 单账号限频是每分钟 60 次Agent 并行执行任务时两三分钟就把配额打满了。后来我做了三件事给工具调用加上频率控制器每个工具的 QPS 单独限制加了退避重试机制遇到限流错误等几秒再试在规划层提示模型这个工具比较慢尽量减少调用次数。改完之后基本不会触发限流了。第二个是文档解析的脏数据问题。很多内部文档导出之后格式乱七八糟有的表格没表头、有的 PDF 扫描件文字顺序是乱的。如果不做清洗直接切块向量检索结果质量会非常差。我们当时花了两周时间专门写一套文档清洗流水线统一转成 Markdown 格式、修复表格结构、去除页眉页脚、识别乱码段落并标记为低质量文本。清洗之后检索命中率上升了约 25 个百分点。第三个是时间相关的问题。用户问最近的版本发布了没这个最近在不同语境下含义不同。处理办法是让 Agent 在调用工具之前先识别问题中的时间意图如果没有明确时间就默认取近 30 天并在回答中说明。否则模型自己猜一个时间范围容易答非所问。3.6 回答质量的评估与调优闭环Agent 系统的评估比传统搜索复杂因为它是生成式的每次输出都可能有差异。我建了一套三层评估机制第一层是自动化规则评估。检查回答是否引用了足够的证据来源、是否包含无法溯源的绝对断言、是否在答案中使用了我不知道来表达信息不足。这层成本最低能拦下明显的问题。第二层是模型评估。用一个评估专用模型不参与回答生成的那个对回答打分维度包括与证据的一致性、信息完整性、表达清晰度。这层可以批量跑用几百个真实问题样例每次修改完 prompt 或工具定义之后跑一遍对比得分的变化。第三层是真实用户反馈。在回答最后加一个有用/没有用的反馈按钮收集用户的显式数据。上线一个月后我们根据反馈数据发现一个有趣的规律用户满意的回答往往都有一个共同特征——引用了具体的、可点击的文档链接。于是我们把每个关键结论必须附带来源链接从建议改成了强制要求整体满意度又升了一截。调优闭环的核心机制是把这三层反馈汇总起来定期形成问题列表。比如某段时间发现用户问项目进度时Agent 老是给出文档里的旧信息而不是调实时接口那就说明意图识别规则需要调整。这种问题列表驱动的迭代比凭空猜效率高得多。4. 常见问题与排查技巧实录4.1 Agent 回答看似合理实际错误怎么破这是 Agent 系统最危险的问题因为它不像系统报错那样明显用户轻易发现不了错误久而久之就对系统失去信任。我们的经验是从三个方向同时堵。第一强制证据链。在 prompt 中明确要求回答中每一个关键判断必须标注来源编号没有来源支撑的内容不得写入回答。生成阶段结束后加一道校验程序检查每个断言是否真的能在证据里找到出处找不到就重写或删掉。这道程序性校验比其他任何 prompt 技巧都管用。第二低置信度触发拒答。设定一个置信度阈值Agent 在生成阶段会给自己一个置信度评估。如果低于阈值宁可回答抱歉我没有在内部文档中找到可靠答案建议联系 XX 团队确认也不要尝试猜测。刚开始我们担心拒答会降低用户体验实际上用户对诚实说不知道的容忍度远高于胡说八道。第三关键数字二次确认。凡是涉及日期、金额、人员、版本号这类精确信息Agent 必须通过工具查询获得不允许从记忆中直接引用。这个规则用 prompt 约束并不完全可靠我后来在工具层做了限制记忆检索模块默认不包含精确数字类信息必须走对应查询工具才能拿到。4.2 大模型规划跑偏、循环不收敛模型在复杂任务中容易出现轴了的情况比如一直重复调用同一个工具、在一个子任务上圆圈打转。我们的处理办法是在规划层设置护栏。第一个护栏是最大迭代次数和最大工具调用次数的硬限制。这两条是硬编码的模型无论如何都突破不了。超过上限就强制结束当前步骤向用户返回该步骤未能完成的提示。第二个护栏是轨迹检查。每次循环之后检查历史动作序列如果发现连续三次调用了同一个工具且参数没有明显变化就判定为重复循环打断循环并要求模型换一种策略。第三个护栏是分步确认。对于关键环节比如准备执行写操作或准备发送外部请求Agent 必须先输出计划执行什么操作、操作原因、预期结果交给人确认后才真正执行。这个不仅防止跑偏还解决了不少合规问题。4.3 LangChain 与开源框架的调试心得用 LangChain 这类框架时最大的痛点是黑盒化——内部抽象太多出了问题不知道卡在哪一层。我的做法是框架只做翻译不做大脑。具体来说框架负责的事情有标准化调用各家模型、把工具函数包装成模型能识别的 Schema、提供向量存储的连接器。而所有涉及 Agent 核心决策的环节包括规划 prompt、执行循环、记忆增删策略都写在自有代码里不依赖框架的高级抽象。这样做的代价是少了一些现成的算子但换来了对系统每一步的完全掌控。真出了问题我可以单独测试每一个环节定位时间缩短了数倍。还有一个小技巧把每一步模型的原始输入输出都记录下来存成可分级的日志。调试 Agent 和调试普通程序最大的不同是普通程序你查堆栈就行Agent 你得读心。而模型做一个决策的原因往往就藏在它的输入上下文里——哪个工具描述吸引了它、哪个历史信息误导了它翻日志才能找到根因。4.4 常见问题速查表我把调试期间遇到的高频问题整理成一个速查表方便遇到类似情况时对照排查。症状可能原因排查顺序Agent 选错工具工具描述不清晰、相似工具过多先检查工具描述是否有歧义再检查工具数量是否过多回答引用来源错误检索阶段召回不准确检查文档切块大小、向量检索 topK、是否缺少 rerank某一步骤反复失败工具依赖的参数格式太复杂简化参数把复杂参数封装成对象或预设模板对话稍长就失忆短期记忆被压缩太狠提高摘要保留粒度关键事实单独抽出来存调用成本暴涨规划步骤过碎、无意义的工具调用过多调大步骤粒度设置工具调用上限回答风格不稳定生成 prompt 约束不够增加风格约束、固定回答模板、加 few-shot 示例系统响应太慢串行调用模型太多将无依赖的工具调用改为并行模型切换为更快版本4.5 避坑清单一些用真金白银换来的经验最后分享几条不按套路出牌的经验每一条都是踩过坑之后才总结出来的。第一条不要在 prompt 里写你要一步步思考。这句话对一个模型可能有用但对生产 Agent 来说它会导致模型把每个细节都拆成天书般的步骤token 花了很多效果却没提升。更好的做法是明确告诉它目标、可用资源、约束条件让它自由发挥。第二条工具命名要像人话。工具名不是给程序看的是给模型看的。get_data_v3这种名字模型理解不了get_project_progress_by_name这种名字一看就懂。命名清晰工具选择准确率会有一个明显的提升。第三条测试集要跟上迭代速度。每次改 prompt 或工具定义都必须跑一遍回归测试集。我们有一个 200 条问题的固定测试集每轮改动之后全部跑一遍用模型打分对比前后差异。没有这个测试集你会发现每次改动都是一次盲改效果像抽奖。第四条上线前一定要加半自动模式。不要一上来就完全无人值守前两周运行期Agent 的每个关键决策都输出给运维人员过目攒一批真实运行日志把高频失败的场景处理完之后再逐步切换到自动模式。结尾一点个人体会这套 Agent 系统从立项到稳定运行前后花了将近四个月。如果让我重新做一次我会把更多时间花在工具设计和数据清洗上而不是焦虑地研究最新的模型推理技巧。Agent 的骨架是工程血肉是工具和数据模型只是驱动它们的动力源。最后分享一个一直提醒自己的判断标准一个 Agent 系统好不好不是看它跑起来多酷而是看它能不能在没人盯着的时候默默把事情做好出了问题也知道如何求助。能做到这一点再朴素的技术栈都是好系统。
阅读完成 · 觉得有帮助？
