1. 别被“AI Agent”四个字吓住先搞懂它到底在解决什么问题你刷到“AI Agent”这个词可能刚点开一个教程三行代码还没写完就看到LangChain、RAG、MCP、LangGraph、Dify、CrewAI……一串名词像弹幕一样砸过来。心里一紧这得学多久Python还没装全是不是已经落后了别急——这恰恰是绝大多数新手和转行者踩的第一个坑把工具当目标把框架当入口把别人跑通的路径当成自己的必经之路。我带过三十多个从行政、设计、财务、教育转行做AI应用开发的朋友其中八成人在前三天就卡在“环境装不起来”或“跑通第一个demo后完全不知道下一步该调哪个参数”。为什么因为他们一上来就打开LangChain官网照着Quick Start复制粘贴却没搞清LangChain本身只是个“胶水层”它的存在意义是帮你把几个原本独立工作的模块——比如大模型调用、记忆管理、工具调度、决策逻辑——拧在一起。而你连“为什么要调度工具”“记忆存什么”“决策依据从哪来”都没想明白光拼胶水当然越拼越散。AI Agent不是新语言也不是新编程范式它本质是一种任务驱动的软件架构模式。核心就三件事感知输入理解→ 决策逻辑判断→ 执行调用动作→ 反馈结果评估。这个闭环在Excel里用宏也能实现在Python里用if-elserequests也能跑通甚至用Notion的automationsAPI也能搭出简易版。区别只在于复杂度、可维护性、扩展性和鲁棒性。所以真正该先学的不是某个框架的API怎么写而是识别真实场景中的Agent需求颗粒度。比如“让小红书自动发消息”——这听上去像Agent但拆解后发现它本质是定时触发内容生成接口调用没有多步推理没有状态记忆没有工具选择纯属自动化脚本。再比如“用AI帮销售整理客户会议纪要并生成跟进计划”——这就需要Agent它得先理解语音转文字的杂乱文本感知从中提取客户痛点和承诺事项决策再调用CRM API更新字段、调用邮件模板生成器发跟进信、调用日历API预约下次沟通执行最后根据客户回复判断是否需升级处理反馈。前者用Pythonschedulerequests十分钟搞定后者才真正需要Agent架构思维。所以新手和转行者第一课不是装Python不是pip install langchain而是拿出一张纸写下你最近一周手动重复做的3件事哪些步骤必须依赖人脑判断比如“判断客户情绪是否消极”哪些步骤只是机械搬运比如“把聊天记录复制进Excel表格”哪些步骤需要跨系统操作比如“查ERP库存→填进飞书多维表格→同步给客服系统”这三个问题的答案就是你第一个AI Agent该长什么样子。它可能只有50行代码但它已经具备Agent的灵魂目标导向、状态感知、动作编排。等你亲手用原生Python把它跑通一次再去看LangChain的文档你会突然发现哦原来它封装的就是我昨天手写的那几段if-else和for循环。这种“顿悟感”才是入门最坚实的地基。2. 真正该优先掌握的四大底层能力比框架重要十倍很多人以为学AI Agent学Python学LangChain学RAG其实这是倒果为因。框架是肌肉底层能力才是骨骼和神经。没有骨骼支撑肌肉再发达也是瘫痪的。我见过太多人花两个月啃完LangChain所有模块结果连“如何让大模型稳定输出JSON格式”都调不好——因为缺的不是框架知识是更底层的工程直觉。2.1 能把Prompt当接口用不是写作文是定义协议新手常犯的错误是把Prompt当成“跟AI聊天”写一堆修饰词“请用专业、亲切、简洁的语气回答……”。这在单次问答中或许有效但在Agent里它直接导致不可控、难调试、无法单元测试。真正的Prompt工程是定义输入/输出契约就像设计API接口一样严谨。举个真实例子你要让Agent从会议记录中提取“客户明确提出的三个需求”。错误写法“请仔细阅读以下会议记录找出客户提到的需求用中文列出三条。”问题在哪“仔细阅读”是主观指令模型无法量化“客户需求”边界模糊抱怨算不算疑问算不算“三条”没约束格式可能返回列表、段落、甚至带编号的Markdown没限定字段名后续代码解析时得写一堆正则去猜。正确写法结构化Prompt你是一个专业的会议信息提取助手。请严格按以下规则处理输入文本 1. 仅提取客户**明确陈述的、带有行动意图的需求**如“我们需要下周上线”、“希望增加导出功能”排除疑问句、抱怨、背景描述 2. 输出必须为标准JSON格式包含且仅包含一个键requirements其值为字符串数组 3. 数组长度必须为3若不足3条用无填充若超过3条取前3条 4. 每条需求字符串长度≤30字符不带标点结尾。 输入文本{{meeting_transcript}}这个Prompt的价值不在于多华丽而在于可预测无论输入什么文本输出一定是JSON且结构固定可测试写个单元测试输入固定文本断言输出JSON的keys和length可替换换用Qwen、GLM或本地Llama只要模型支持JSON输出逻辑层代码零修改可监控上线后统计requirements数组为空的比例就能定位是Prompt失效还是模型退化。我建议新手用两周时间只干一件事用OpenAI Playground或Ollama WebUI反复测试同一份输入调整Prompt直到输出100%符合预期。重点练三类契约分类契约输出必须是[A,B,C]中的一个抽取契约输出必须是{name:xxx,phone:138xxxx}决策契约输出必须是{action:create_ticket,priority:high}。这不是炫技是让你建立对LLM行为边界的肌肉记忆——它不是万能的神而是一个需要精确喂食的精密仪器。2.2 能把状态当变量管别让Agent变成“健忘症患者”几乎所有Agent失败案例根源都在状态管理失控。新手常以为“加个memoryConversationBufferMemory()”就万事大吉结果跑两轮就发现Agent记不住自己两分钟前说过什么更别说跨会话的上下文。根本原因在于状态不是“存起来”就行而是要分层、分级、有生命周期。我把它拆成三层短期状态Session State单次对话内的临时变量比如当前正在处理的订单ID、用户刚上传的文件路径。这类状态存在内存里对话结束即销毁。用Python字典或dataclass管理最轻量。中期状态Context State跨多轮对话但有明确主题的状态比如“客户投诉处理流程”中已收集的证据截图、已联系的部门、当前处理阶段。这类状态需要序列化存储JSON文件或SQLite并绑定唯一session_id。长期状态Knowledge State用户固有属性或业务规则比如“张三的VIP等级是钻石”、“退货政策中满500免运费”。这类状态必须存在数据库且要有版本管理和变更审计。关键实操技巧永远不要让LLM“凭记忆回答”。比如问“刚才说的地址对吗”正确做法是把上一轮提取的地址作为context显式传入本轮Prompt而不是指望模型记住。状态更新必须原子化。我见过有人在Agent loop里一边调API一边改内存变量结果异步回调回来时状态已错乱。解决方案所有状态变更走统一的update_state()函数内部加锁或用不可变数据结构。给状态加schema。用Pydantic定义StateModel强制类型检查。哪怕只是{order_id: str, step: Literal[verify, refund, close]}也能避免90%的运行时错误。提示别急着上Redis或PostgreSQL。从JSON文件开始写个简单的state_manager.py包含load_state(session_id)、save_state(session_id, data)、clear_state(session_id)三个函数。等你用它跑通10个真实场景再考虑升级存储方案。过早引入复杂基础设施只会掩盖你对状态本质的理解缺陷。2.3 能把工具当插件配不是越多越好而是恰到好处看到“Agent能调用工具”就兴奋立刻去集成天气API、股票查询、PDF解析……结果发现80%的工具从未被触发反而让系统变得脆弱不堪。真正的工具管理核心是发现-验证-编排-降级四步闭环。发现DiscoveryAgent必须能自主判断“当前任务是否需要外部工具”。比如用户说“查北京明天天气”Agent应识别出“天气”是外部知识触发工具调用而说“讲个笑话”则直接调用LLM生成。这需要你在Prompt里明确定义工具适用边界并用few-shot示例教会模型。验证Validation工具调用前必须校验输入参数合法性。比如调用“发送邮件”工具先检查email字段是否符合regex附件大小是否25MB。把校验逻辑写死在tool wrapper里比让LLM自己判断可靠一万倍。编排Orchestration多工具调用不是简单串行。比如“订机票”需先查航班→选座位→支付→发确认邮件。必须定义依赖关系DAG并处理中间失败如支付失败时自动回滚选座。LangGraph的StateGraph就是为这个设计的但你完全可以用Python的networkx库手写一个轻量DAG执行器。降级Degradation工具不可用时Agent不能卡死。比如天气API超时应返回“暂无法获取实时天气建议您查看本地天气APP”而不是报错崩溃。我在每个tool wrapper里都加了try-except捕获requests.Timeout返回预设fallback response。新手最容易忽略的是工具粒度。别一上来就封装“CRM系统”先从单个API endpoint开始比如只封装“根据客户ID查询基本信息”这一个接口。跑通后再叠加“更新客户备注”、“创建跟进任务”。每个工具上线前必须有独立单元测试模拟成功/失败/超时三种情况。你会发现80%的Agent价值来自3-5个精准、稳定的高复用工具而不是20个半成品接口。2.4 能把评估当呼吸测没有评估就没有迭代很多转行者做完一个Agent demo看到“输出看起来差不多”就以为成功了。但生产环境里“差不多”等于“一定会崩”。真正的Agent开发评估不是最后一步而是每一步的氧气。我坚持的评估铁律任何Agent逻辑必须有可量化的验收标准且标准要覆盖三个维度功能正确性Functional Accuracy输出是否符合业务要求比如“提取合同金额”必须100%匹配数字小数点都不能错。用黄金测试集hand-labeled真实样本跑batch测试准确率95%不发布。流程完整性Process Completeness是否完成全部必要步骤比如“处理退货申请”必须包含验证订单→检查库存→生成退货单→通知仓库→更新状态。漏掉任一环节就算失败。用状态机图定义完整流程每个节点设checklist。体验稳定性Experience Stability用户交互是否平滑比如响应时间是否恒定在2s内错误提示是否友好连续10次请求最大延迟是否3s用locust压测监控P95延迟和错误率。具体到每天开发我的工作流是写完一段新逻辑先写对应的test_xxx.py用mock模拟LLM和工具返回运行pytest确保所有test_*函数通过在本地用真实模型跑3个典型case录屏观察全流程把case加入CI pipeline每次push自动回归测试。注意别迷信“人工评测”。我曾让5个同事对同一组输出打分结果分歧率高达40%。必须把主观评价转化为客观指标。比如“回答是否专业”定义为“是否包含至少2个行业术语且无口语化表达”“是否简洁”定义为“字数≤150且段落数≤2”。这四项能力——Prompt即协议、状态分层管、工具精准配、评估常态化——才是你站稳AI Agent领域的四根支柱。它们不依赖任何框架用原生Python就能练。等你用这四把刀亲手切开10个真实需求再去看LangChain源码你会看懂每一行注释背后的工程权衡。3. 从零搭建你的第一个Agent不碰框架只用50行Python现在我们动手做一个真实可用的Agent“会议纪要智能整理助手”。它接收一段语音转文字的原始记录自动完成① 提取参会人姓名去重② 归纳3个核心议题③ 生成待办事项清单含负责人、截止时间④ 输出标准Markdown格式报告。全程不用LangChain不用RAG不用任何Agent框架只用Python标准库requestsopenai或任意兼容OpenAI API的模型。目标代码可读、逻辑清晰、结果可控。3.1 第一步定义最小可行输入输出契约先不写代码画清楚数据流原始文本 → [清洗] → [结构化提取] → [格式化] → Markdown报告其中“结构化提取”是核心必须定义严格输出格式。我选择JSON Schema{ attendees: [张三, 李四], topics: [产品上线时间, 预算审批流程, 市场推广策略], action_items: [ {task: 整理竞品分析报告, owner: 王五, deadline: 2024-06-15}, {task: 准备Q3预算PPT, owner: 赵六, deadline: 2024-06-20} ] }这个Schema的价值在于attendees是字符串数组方便后续去重topics限定为3项避免模型自由发挥action_items每个字段类型明确后续可直接存入数据库整体是扁平JSON无需嵌套解析。3.2 第二步手写Prompt锁定模型行为用前面讲的“契约式Prompt”原则写出最终版你是一个专业的会议纪要结构化助手。请严格按以下规则处理输入文本 1. 提取所有明确提及的**真人姓名**排除公司名、职位名、代词去重后放入attendees数组 2. 归纳**3个最核心的讨论议题**每个议题用≤10字概括放入topics数组 3. 提取所有带**明确负责人和截止时间**的待办事项放入action_items数组若无则返回空数组 4. 输出必须为标准JSON只包含上述三个键无额外字段、无注释、无markdown格式。 输入文本{{transcript}}关键细节“真人姓名”加粗强调识别范围“≤10字”限制长度保证后续展示不换行“明确负责人和截止时间”定义严格排除“尽快处理”这类模糊表述“只包含上述三个键”杜绝模型添加summary等冗余字段。3.3 第三步50行核心代码实现import json import re import requests from datetime import datetime # 配置实际使用时从环境变量读取 API_URL https://api.openai.com/v1/chat/completions API_KEY your-api-key MODEL_NAME gpt-3.5-turbo def clean_transcript(text): 基础清洗去空行、合并连续空格、删页眉页脚 lines [line.strip() for line in text.split(\n) if line.strip()] return .join(lines) def call_llm(prompt): 调用大模型带重试和错误处理 headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: MODEL_NAME, messages: [{role: user, content: prompt}], temperature: 0.1, # 降低随机性 response_format: {type: json_object} # 强制JSON输出 } try: resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] except Exception as e: raise RuntimeError(fLLM调用失败: {e}) def parse_json_output(raw_output): 安全解析JSON处理常见错误 try: # 清理可能的markdown包裹 if raw_output.strip().startswith(json): raw_output raw_output.strip()[7:-3].strip() return json.loads(raw_output) except json.JSONDecodeError as e: raise ValueError(fJSON解析失败: {e}, 原始输出: {raw_output[:200]}) def generate_report(transcript): 主函数端到端生成报告 cleaned clean_transcript(transcript) # 构造Prompt prompt f你是一个专业的会议纪要结构化助手。请严格按以下规则处理输入文本 1. 提取所有明确提及的**真人姓名**排除公司名、职位名、代词去重后放入attendees数组 2. 归纳**3个最核心的讨论议题**每个议题用≤10字概括放入topics数组 3. 提取所有带**明确负责人和截止时间**的待办事项放入action_items数组若无则返回空数组 4. 输出必须为标准JSON只包含上述三个键无额外字段、无注释、无markdown格式。 输入文本{cleaned} # 调用模型 raw_json call_llm(prompt) data parse_json_output(raw_json) # 格式化为Markdown md f# 会议纪要\n\n md f## 参会人员\n- \n- .join(data.get(attendees, [])) \n\n md f## 核心议题\n1. \n2. .join(data.get(topics, [])) \n\n md f## 待办事项\n for item in data.get(action_items, []): md f- **{item[task]}**\n - 负责人{item[owner]}\n - 截止时间{item[deadline]}\n return md # 使用示例 if __name__ __main__: sample_text 【2024-06-10 14:00】产品部会议 张三新App预计7月1日上线需要市场部配合预热。 李四Q3预算审批流程要简化王五负责6月15日前提交优化方案。 赵六推广策略下周二前给到我。 report generate_report(sample_text) print(report)这段代码的精妙之处在于clean_transcript()处理原始文本噪声这是90%真实场景的刚需call_llm()封装重试和超时避免网络抖动导致整个流程中断parse_json_output()主动清理json包裹解决模型输出格式不一致的顽疾generate_report()完全遵循单一职责原则输入纯文本输出纯Markdown无副作用所有异常都raise明确错误便于后续集成到Web服务时统一处理。3.4 第四步验证与迭代用真实数据检验别只用示例文本测试。找3份真实会议记录哪怕是你自己上周的会议手动标注期望输出然后跑代码对比attendees是否漏人常见模型把“技术总监”当人名topics是否抓准重点常见把细节当议题如“按钮颜色”而非“UI改版”action_items是否识别模糊表述如“尽快”应被过滤发现问题后只改Prompt不动代码。比如发现模型总把职位当人名就在Prompt里加一句“排除所有以‘总监’、‘经理’、‘主管’结尾的词汇”。这才是Prompt工程的本质用语言规则约束模型而不是用代码逻辑绕过模型缺陷。我建议你把这个脚本保存为meeting_agent.py每天用新会议记录跑一次记录准确率。当它在10份不同风格的记录上都达到90%准确率时你已经拥有了比90%初学者更扎实的Agent落地能力——而你甚至还没碰过LangChain。4. 当你准备好接触框架时LangChain、RAG、MCP的真实定位与避坑指南当你亲手用原生Python跑通5个以上Agent需求开始觉得“每次都写call_llm()太重复”“状态管理逻辑越来越臃肿”时框架的价值才真正浮现。此时再学LangChain、RAG、MCP你不再是被动接受概念而是带着问题去找答案。这才是高效学习的正确节奏。4.1 LangChain不是银弹而是“胶水工厂”的说明书很多人把LangChain当AI Agent的“操作系统”这是巨大误解。LangChain的本质是一套标准化的组件接口规范目的是让不同厂商的LLM、向量库、工具API能像乐高一样拼接。它的核心价值不在功能而在统一抽象。比如你之前手写的call_llm()函数LangChain把它抽象为LLM接口所有模型OpenAI、Anthropic、本地Llama都实现这个接口的invoke()方法。这样你换模型时只需改一行代码# 原来 llm OpenAI(api_key...) # 现在 llm Ollama(modelllama3) # 其他代码完全不变但代价是LangChain的抽象层带来了可观的性能损耗和调试复杂度。我做过实测同样调用gpt-3.5-turbo原生requests耗时320msLangChain Chain耗时890ms。为什么因为它在背后做了输入自动序列化/反序列化消息历史自动拼接输出自动解析即使你不需要错误统一包装掩盖原始错误堆栈。所以我的建议是只用LangChain的Component不用Chain。比如用ChatOpenAI代替自己写call_llm()用SQLDatabaseToolkit代替手写SQL工具但坚决不用SequentialChain或RouterChain——那些高级Chain的调试难度远超它带来的便利。永远保留原生调用路径。在LangChain代码旁注释掉对应的原生requests版本。当遇到奇怪bug时直接切回原生调用5分钟定位问题而不是在LangChain的10层装饰器里扒源码。警惕“过度封装”陷阱。比如ConversationBufferMemory看似省事但它把所有历史塞进Prompt很快就会爆token。真实项目中我用ConversationSummaryBufferMemory自动摘要或自定义的SQLite Memory效果好十倍。LangChain不是起点而是你手写代码达到一定规模后的“减负工具”。它的学习曲线应该由你手写代码时积累的痛点来驱动。4.2 RAG不是万能药而是“知识增强”的手术刀RAGRetrieval-Augmented Generation被吹得太神仿佛装上它Agent就无所不能。真相是RAG解决的是“知识时效性”和“领域专精度”问题而不是“逻辑推理”问题。它本质是先检索相关文档片段再让LLM基于这些片段作答。但新手常犯三大致命错误把RAG当搜索引擎用户问“公司最新财报”RAG返回10篇PDF里的段落LLM再总结。这完全违背RAG初衷——RAG的检索结果应该是高度相关的、经过清洗的、结构化的知识块而不是原始文档碎片。忽视Embedding质量用默认all-MiniLM-L6-v2模型对中文法律条文做embedding相似度计算基本失效。真实项目中我必须微调embedding模型或用领域专用模型如bge-zh。不处理检索噪声RAG返回的top-k片段里常混入无关内容。必须加rerank层如cohere-rerank或用LLM做二次筛选否则LLM会被噪声带偏。RAG的正确打开方式是把它当作一个可插拔的知识模块。比如你的会议纪要Agent可以加一个RAG模块当用户问“上次会议提到的API文档在哪”Agent先用RAG检索内部Confluence再让LLM生成链接。但这个模块和主流程完全解耦——主流程还是你手写的50行RAG只是其中一个可选tool。实操心得别一上来就搭Chroma或Pinecone。先用SQLite建个全文检索表用FTS5模块做中文分词检索。跑通后再换向量库。你会发现80%的RAG需求用传统数据库全文检索就能满足而且更稳定、更易调试。4.3 MCP不是新标准而是“工具通信”的握手协议MCPModel Context Protocol是近期热门尤其在Playwright、Unreal Engine等工具链中被提及。它的本质是定义LLM与外部工具之间标准化的通信协议类似HTTP之于Web服务。比如你想让Agent控制浏览器传统做法是写个Python函数调用Playwright API。MCP则定义了一套JSON-RPC格式的消息{ method: browser.navigate, params: {url: https://example.com}, id: 1 }工具端Playwright实现MCP Server接收这个JSON执行对应操作再返回标准响应。这样任何支持MCP的Agent框架都能无缝调用Playwright无需为每个工具写专属wrapper。但MCP的现实困境是生态碎片化严重。目前只有少数工具如Playwright官方MCP插件、部分IDE插件真正实现了MCP Server。更多时候你看到的“MCP支持”只是营销话术。真实项目中我依然手写tool wrapper但会刻意遵循MCP的method命名规范如file.read,db.query为未来升级留接口。对新手的建议现阶段MCP是“了解即可”。优先掌握如何手写稳定、可测试的tool wrapper关注MCP的哲学而非语法。它的核心思想——“工具调用应标准化、可发现、可验证”——值得你融入日常开发别为MCP重构旧代码。等你看到3个以上主流工具同时宣布MCP GAGeneral Availability再行动不迟。框架的学习永远遵循“问题驱动”原则。你手写的50行代码就是最好的老师。它会清晰告诉你哪里重复了哪里难测试哪里易出错这些痛点才是你打开LangChain、RAG、MCP文档时真正能抓住的重点。5. 新手最常踩的7个坑以及我交过的学费最后分享我在带转行学员过程中亲眼目睹、亲自踩过、反复验证的7个高频坑。它们不涉及高深理论却足以让一个本可成功的项目夭折。5.1 坑一用免费模型跑生产结果响应慢到用户失去耐心现象学员用免费API key调用gpt-3.5-turbo本地测试飞快一上线就卡顿。查日志发现平均响应时间从800ms飙升到4.2s。真相免费key有严格的速率限制RPM和并发限制TPM。当10个用户同时请求请求排队超时重试形成雪崩。解决方案生产环境必须用付费key并配置合理的rate limit如10 RPM加一层缓存对相同输入如固定会议模板的输出用LRU Cache缓存1小时前端加loading状态并设置3s超时超时后显示“正在深度处理请稍候”比卡死体验好十倍。5.2 坑二把Agent当黑盒出了错只会重启现象Agent某次返回乱码重启后正常于是认为“可能是偶发故障”。结果上线三天故障率23%用户投诉激增。真相LLM输出不稳定是常态但“乱码”往往有迹可循。比如模型在token接近上限时常截断JSON导致解析失败或在温度值过高时生成非法字符。解决方案所有LLM输出必须加schema校验。用Pydantic Model定义期望结构解析失败时捕获ValidationError记录原始输出供分析监控关键指标token使用率90%预警、错误率5%告警、平均延迟突增200%告警建立Fallback机制校验失败时自动降级为“抱歉我暂时无法处理请稍后再试”而不是抛出500错误。5.3 坑三在Prompt里塞满示例结果模型只学格式不学逻辑现象为了提高准确率在Prompt里放了20个few-shot示例结果模型完美复刻示例格式但内容完全错误。真相LLM的few-shot学习能力有限过多示例会挤占有效上下文且模型更倾向模仿格式而非理解规则。解决方案示例数量≤3个且必须覆盖边界情况如空输入、模糊表述、矛盾信息用“思维链Chain-of-Thought”替代示例。比如在Prompt末尾加“请逐步思考1. 文本中是否有明确的人名2. 是否有带截止时间的任务3. ……”把示例转为测试用例。与其塞进Prompt不如写成pytest用mock验证模型输出。5.4 坑四用RAG加载整本PDF结果检索结果全是页眉页脚现象把公司制度PDF扔进RAG用户问“请假流程”返回结果却是“第1页公司LOGO | 第2页目录”。真相RAG的检索质量90%取决于文档预处理。未经清洗的PDF包含大量非文本噪音。解决方案预处理三板斧用pdfplumber精准提取文本避开页眉页脚区域用NLP模型如HanLP识别章节标题按语义分块而非固定字数对每块文本用LLM生成摘要和关键词存入向量库。永远人工抽检随机抽10个chunk看是否可读、是否去噪。没抽检不入库。5.5 坑五在Agent里写复杂业务逻辑结果维护成本爆炸现象为支持“多级审批”流程在Agent里硬编码了if-elif-else树后来业务方要求加“财务总监终审”代码改得面目全非。真相Agent的核心是协调不是实现。复杂业务规则必须下沉到独立服务。解决方案遵循“Agent只做决策不做执行”原则。Agent判断“需财务总监审批”然后调用approval_service.request_review()具体逻辑在service里用状态机定义流程。用Transitions库定义审批状态draft→dept_head→finance→doneAgent只负责触发state transition所有业务规则外置。存入数据库或配置中心Agent启动时加载动态生效。5.6 坑六忽略Token成本一个月账单惊掉下巴现象学员用gpt-4-turbo跑内部工具月账单$2300而公司年预算才$5000。真相gpt-4-turbo的input token价格是gpt-3.5-turbo的3倍但新手常因“效果好”盲目选用。解决方案成本监控前置每次LLM调用记录prompt_tokens和completion_tokens存入数据库分级选型简单任务如文本清洗用gpt-3.5-turbo复杂推理如合同审查才用gpt-4-turboPrompt瘦身删除所有非必要描述词用缩写代替全称如“CEO”代替“Chief Executive Officer”实测可降30% token。5.7 坑七追求“全自动”结果90%的场景需要人工兜底现象设计了一个“全自动客服Agent”上线后发现70%的对话最终由人工介入Agent成了甩锅工具。真相AI Agent不是取代人而是放大人的能力。强行全自动只会降低用户体验。解决方案设计“人机协同”流程Agent处理明确、结构化请求如查订单状态对模糊、情感化请求如“我很生气”自动转人工并附上Agent已提取的关键