2. 核心细节解析与实操要点2.1 结构化输出的三重保险既然标题定了“无 Tool Calling”那结构化输出就全靠约束了。我的第一版实现就是纯靠“提示词好话好说”结果效果非常感人——五个样本里三个都能给出合法JSON但只要句子一长、业务字段一多总有模型在中间某处“放飞自我”。所以后来我把结构化输出做成三层保险叠加起来用第一层是系统提示词中的Schema约束。这一步不是把JSON Schema原样丢给模型就完事儿要配合解释说明。我用的模板大概是你的输出必须是一个JSON对象严格匹配以下JSON Schema。 不要输出任何额外文字、代码块标记如json、注释。 如果某个字段没有可用信息使用null填充不要编造。Schema本身尽量精简字段名用语义化命名Enum字段给出可读性强的取值注释。模型毕竟不是机器它对Schema的理解是靠“语义”建立的字段写得越直白约束越有效。第二层是响应解析与结构校验。这一层必须在代码里做不能偷懒。拿到LLM返回的字符串后我用Pydantic定义跟Schema对应的模型再调用model_validate_json()做解析。这个库好用就好在解析不通过时它会告诉我具体是哪个字段、哪种类型对不上定位错误非常方便。每次都把解析失败的内容连同报错信息一起原样记录下来后续做“自纠错”时要用。第三层是自动重试与自我修正。如果解析失败我不会直接报错给用户而是把失败原因和原始响应拼到一条新消息里让模型重写。这条“纠错提示词”我写得很有讲究不是简单说“你错了再试一次”而是明确告诉它哪里错了、期望什么你上一次的输出不合规。以下是具体问题和期望修正方向 - 原始输出[粘贴模型输出] - 校验报错[粘贴Pydantic报错] - 修正要求重新输出完整的JSON对象 确保所有字段符合Schema数组字段至少包含0个元素 枚举字段严格按照给定值之一输出。实测下来执行一次纠错之后成功率能从70%左右拉到接近96%第二轮的纠错空间极大但必须配合重试上限防止陷入死循环。我把重试上限设为2次超过就返回一个带fallback标记的结果宁可让业务层看到“本次Agent处理失败”也不能让脏数据混入下游。2.2 提示词里暗藏的门道行业内有个说法叫“prompt engineering 已经被 LLM 能力增长冲淡了”但那是针对通用问答场景用在Agent上根本不成立。Agent的提示词是逻辑的一部分是真正参与运算的程序代码设计得不好再强的模型也做不稳。我的提示词遵循三个原则原则一给例子而且要放在描述后面紧跟的位置。Few-shot示例不是摆设模型对“例子的格式”的敏感程度远高于对“文字的规则”。给两个对比强烈的示例一个是完全合规的输出一个是带轻微瑕疵比如在JSON后面加了句废话的输出并显式标注后者为什么不合格。这比写十行“不许输出废话”都管用。原则二明确的任务边界比任务本身更容易被遵守。很多人写提示词只告诉模型要干什么不告诉它不干什么。我会把“禁止行为”单独列出来不要推测缺失信息、不要补全未提供的上下文、不要输出自然语言解释。重点来了——这些“禁止”不用祈使句堆砌而是转换成一个“自检清单”让模型在输出前先过一遍。原则三让模型扮演“解析器”而不是“创造者”。我对模型说你的职责不是基于你的知识创作内容而是把用户提供的原始材料做一个“重新整理”。这个身份设定极大地减少了模型自由发挥的倾向性。凡是要模型提取信息的任务它一旦以为自己是“搜索引擎文案大师”你就等着在JSON里读到它自己编出来的知识吧。2.3 路由层设计怎么让一个Agent干多种活“通用Agent”意味着不能给每个业务场景单独开发一套模型和提示词而是靠一个路由层把不同请求分发给不同的“任务处理器”。我的做法非常克制没有上多Agent框架而是用一个轻量级“意图分类器”做内部路由。具体流程是用户输入进来后先由LLM判定这条输入属于哪个领域/意图输出一个简短的结构化标签比如{intent: summary}然后代码根据标签挑选对应的处理模板。这个“意图分类”本身也只调一次LLM而且模型极擅长这种低难度分类任务实测准确率在96%以上。这里的核心考量是不要让路由判断承担太多信息压缩的职责。意图标签只负责“选择路径”不负责“承载结果”业务细节全部留给后续的处理流程。每个处理路径共享同一个输出规范化模块所以在行为上保持一致只有处理逻辑的差异没有输出风格的风险。有一个坑值得提醒意图标签不要设计太细。我有一次把意图分到12个类别模型开始频繁误判两个相似分类之间来回摇摆。收敛到5个主类、每个主类下面再用分支处理子场景之后稳定性好了很多。意图分类必须保持“人类也能一眼区分”的粒度凡是连人都不容易分清的两个类别模型大概率也分不好。2.4 记忆与上下文管理的取舍这个Agent是“通用”且“无工具”的这就意味着它处理的是单轮内的复杂任务而不是长期对话记忆。说白了整个Agent的能力核心是“在有限上下文里把事一次办好”不依赖长期记忆模块。但我还是给短期上下文做了精心管理否则模型很容易在长输入下“忘前头”。上下文裁剪的策略是“三段式”最近3轮对话保留完整原文更早的内容压缩成摘要压缩摘要的字段格式也是JSON。这个摘要由模型在每一轮结束时自动生成存成固定结构新的一轮开始时把它插回上下文。看似简单效果却出乎意料的好——模型的“记忆感”明显增强在连续多轮的结构化抽取任务里字段一致性高了很多。没有用向量数据库做检索记忆这是有意为之。“通用Agent”的定位不是知识问答机器人大多数输入的知识密度并不高向量检索增加的延迟和不确定性反而大于收益。在信息需求确凿的场景比如文档解析、信息抽取“直接塞进上下文”比“检索再召回”更快更准。结论是记忆不是越复杂越好要先想想你的任务到底需不需要记忆。3. 实操过程与核心环节实现3.1 技术栈选型与原因动手之前我先把技术栈定下来避免写到一半被底层库折腾。我的组合是Python LangChain仅用基础组件 Pydantic OpenAI SDK没有引入重型编排框架后面细说为什么。模型选择上我用的是通用对话模型如GPT-4o-mini级别而非代码生成模型。原因在于代码生成模型容易把输出格式带偏成“给程序员看的东西”而通用模型在“模拟人类填写表格”的场景下表现得更加自然。为了控制成本和延迟我还在长任务上使用了异步调用的方式并发处理多个请求这在后面小节展开讲。LangChain在这个项目里只用来管理Prompt模板和输出解析器不用它的Agent执行框架。原因是LangChain的Agent抽象封装了太多逻辑出了问题排查起来像是在解套娃而我们要做的是一个“流程极简、行为透明”的系统。一条处理链路输入 → 意图分类 → 任务处理 → 结构校验 → 输出修正 → 返回每一步都可观测、可单独调试这对“通用Agent”的可维护性至关重要。Pydantic的价值在整套流程里被彻底放大了。我定义的任务模型都继承了BaseModel每个字段写上详尽的Field(description...)。模型在“结构化抽取”场景下对字段描述的理解程度直接决定了抽取质量这相当于免费给模型塞了个语义提示。3.2 核心代码结构详解下面这段代码是我整个Agent骨架的浓缩。结构很简单但每个函数都承担着一个不可省略的职责。import json from typing import Any, Callable from pydantic import BaseModel, ValidationError class AgentInput(BaseModel): raw_text: str user_intent: str | None None class AgentOutput(BaseModel): intent: str data: dict[str, Any] confidence: float fallback: bool False class StructuredAgent: def __init__(self, llm, router_prompt, task_prompts: dict[str, str], max_retries: int 2): self.llm llm self.router_prompt router_prompt self.task_prompts task_prompts self.max_retries max_retries def _classify_intent(self, raw_text: str) - str: # 轻量意图分类输出固定为{intent: xxx} resp self.llm.chat( messages[ {role: system, content: self.router_prompt}, {role: user, content: raw_text}, ], response_format{type: json_object}, ) parsed json.loads(resp) return parsed[intent] def _run_task(self, intent: str, raw_text: str) - str: prompt self.task_prompts[intent] resp self.llm.chat( messages[ {role: system, content: prompt}, {role: user, content: raw_text}, ], response_format{type: json_object}, ) return resp def _validate(self, intent: str, raw_json: str) - AgentOutput: # 此处简化处理实际应针对每种intent做字段级校验 parsed json.loads(raw_json) return AgentOutput( intentintent, dataparsed, confidenceparsed.get(confidence, 0.8), ) def run(self, raw_text: str) - AgentOutput: intent self._classify_intent(raw_text) last_error None for attempt in range(self.max_retries 1): raw_resp self._run_task(intent, raw_text) try: return self._validate(intent, raw_resp) except (json.JSONDecodeError, ValidationError) as e: last_error str(e) # 把错误信息回喂给模型 raw_text ( f本次输出非法错误原因{last_error}。 f原始输出{raw_resp}。请严格按照schema重新输出完整JSON。 ) return AgentOutput( intentintent, data{}, confidence0.0, fallbackTrue )这段代码是“能用”的程度但不是我最终线上跑的版本。生产版本多做了两件事一是引入异步并发处理用asyncio.gather一次处理多个用户请求二是给每个请求加了超时控制和异常隔离某个请求的失败不会拖垮整批任务。3.3 并发与性能一个Agent扛住高并发请求热词里有人搜“AI Agent怎么扛并发”恰好我在这块做过压测可以分享一下粗糙经验。单机部署下基于LLM的Agent瓶颈不在代码而在两类资源模型API的速率限制、以及并发请求时的上下文内存占用。第一个瓶颈处理方式是令牌桶限流加指数退避重试。API返回429或连接超时我没有立刻报错而是做一个简单的退避等待再试退避的时间间隔按照0.5s * 2^n递增最大不超过8秒。实测这个策略能把“瞬时高峰请求”稳稳送进API而不会触发封禁。第二个瓶颈处理方式是控制单个请求的Token预算。我用tiktoken在进入系统前先估算总Token数超过预设阈值的输入先做分段处理再合并。这个做法对成本的影响也很大因为结构化输出往往比普通对话更耗Token。并发压测数据上我用一个8核16G的轻量云主机跑同步版本QPS稳定在3.5左右改成异步版本后提升到11左右。瓶颈确实在LLM响应时长代码本身的耗时占比很小这也是为什么我说“Agent扛并发”的关键不在写代码而在合理管理调用策略。3.4 模型选择与降本增效有关“Agent开发用什么模型”这个问题小红书上的回答真是花里胡哨。实际上我的结论很简单小任务用小模型大任务用大模型不要一套模型打天下。意图分类这种低复杂度任务用mini级别就够又快又便宜。内容抽取、复杂推理任务才切到标准模型。成本上我按“每万次请求”算过账全用大模型跑成本约是“大小模型混合调度”的4倍而准确率差异不到1个百分点。所以做通用Agent时模型分级调度是降本的第一杠杆。还要提一嘴结构化输出模式。最新模型已经原生支持JSON响应格式这让输出合法JSON的概率提高了不少比靠提示词硬掰可靠。但这个能力只解决了“语法合规”没有解决“语义准确”业务字段的抽取质量还是得靠任务提示词。不要以为开了JSON模式就万事大吉做字段级校验永远是最后一道防线。4. 常见问题与排查技巧实录4.1 模型输出总是差一口气如何定位“脏”字段拿到不合规JSON后第一步不是改提示词而是得分清楚“脏”在语法层还是语义层。语法层问题是JSON本身不合法逗号多了一个、引号缺了一个。这类问题用Pydantic的报错信息就能定位一般加一轮纠错就能清掉。语义层问题才是大头。模型的输出是合法JSON但内容不对比如字段值张冠李戴、数组里混进了多余元素。这没法靠校验器发现只能人工抽查。我常用的办法是构建一个小型“黄金样本集”大约50条典型输入每轮改动Prompt后都跑一遍这个样本集人工对比抽取结果。虽然费时间但这是唯一能守住质量底线的办法。另一个排查技巧是让模型“自解释”。不是让它在正式输出里加解释而是在调试模式下额外生成一段“你为什么提取这个值”的说明。模型说得清楚通常说明它理解了任务一旦语焉不详大概率是猜的回去改提示词。这个小技巧帮我精确绕开过好几个糊弄场景。4.2 意图分类误判时的兜底策略再好的路由方案也有误判的时候尤其在用户输入模棱两可时。我给Agent设了一条兜底规则当意图分类置信度低于阈值时不直接走任何任务分支而是进入“澄清模式”。澄清模式下的输出也是一个JSON包含一个clarifying_question字段由外层代码决定是直接展示给用户还是走默认分支。“澄清模式”不是让模型反复问用户“你是什么意思”那样体验太烂。我只允许Aladdin一级澄清最多问一个最可能区分意图的问题。例如意图同时命中“摘要”和“翻译”时问一句“你希望我为你翻译还是概括这段内容”已经足够。一级澄清经费别用多用多就成了客服机器人。兜底策略的第二层是 “默认处理器”。如果意图分类模型连续三次给出低置信度我直接把这个请求送到一个“通用结构化转换器”它不绑定任何特定业务场景只负责把用户原始输入转换成一份“泛信息结构”标题、要点、原文摘录保证用户至少拿到一个可用的结果而不是一个冷冰冰的报错。4.3 长文本输入导致的上下文截断这个坑我踩得最惨的一次是处理一份长达两万字的合同扫描文本时Agent输出内容中间突然开始胡言乱语最后还返回了一个不完整的JSON。排查后确认问题的根源是上下文超出了模型的窗口限制模型只能看到前一段后面的业务关键信息全丢了。解决思路不是简单截断而是给长文本做了“分块逐块提取合并”的处理链。首先把长文本按段落或语义边界切分成多个块每块控制在模型上下文窗口的一半以内。每个块单独跑一次结构化抽取得到该块的局部结果。再把所有局部结果汇总让模型做二次融合生成一份统一结构的输出。这个“分而治之”方案听起来冗余实际效果非常稳定——单次抽取的准确率从截断时的不到50%提升到了稳定在88%以上。代价是API调用次数变多所以只在输入长度超过阈值时才启用分段模式。4.4 结构化输出与业务场景的匹配度纠偏“结构化Agent”最容易出现的问题是技术上输出格式完美但业务上毫无用处。比如一个客户投诉分类任务模型输出了一大堆通用字段标题、摘要、情感倾向但业务方真正需要的“投诉类型”、“责任部门”、“紧急程度”反而没提取出来。这类问题不是模型笨而是Schema设计脱离了业务。我的修正办法是在设计Schema前先跟业务方确定“这个字段如果为空业务还跑不跑得起来”。凡是“为空就跑不起来”的字段必须让它成为模型抽取的强制关注点在提示词里单独加粗说明。凡是“只有最好有”的字段一律放到可选字段组不让它们分散模型注意力。Schema的字段数量建议控制在8到12个超过这个范围单次抽取的准确率会开始明显下降。字段命名也同样重要。我坚持用业务术语命名而不是通用术语。比如电商场景里“退款原因”绝不要命名为“reason”因为模型对这种宽泛字段的处理往往是模糊的。把字段名写成“customer_refund_reason”加上示例值之后模型的抽取质量会有肉眼可见的提升。4.5 成本失控的预警与治理无Tool Calling方案里最容易成本失控的环节就是“自纠错”。每多一次纠错就多一轮API调用而纠错轮次的输出Token往往比首轮更长它要复述修正日志。我曾看到一次纠错把单请求的Token消耗拉到首轮的3倍必须设上限。治理手段是三层第一层是总轮次上限上面代码里的max_retries写死不超过2第二层是Token上限单次请求如果预计超过预设阈值直接转为分段处理而不是让模型硬啃第三层是告警实时监控纠错率当一个小时内的纠错率超过10%就触发警告提示去检查提示词稳定性。纠错率突然飙升往往是上游输出来源变了比如新版本模型上线早发现比晚补救强太多。4.6 安全守护Agent输出可信度如何把控Agent的输出不是给人看的文案而是直接参与业务逻辑的数据所以可信度是硬指标。我的系统里专门加了一个confidence信号由模型在输出时自评。这个自评能力在常规任务中并不可靠所以我会在业务层再做一道交叉验证凡是置信度低于0.7的结果一律转入人工审核队列。另外当系统检测到用户输入里含有诱导性指令比如让Agent忽略系统提示词、改变输出角色等时我不会直接拒绝而是把结果标记为“low_trust”并保持结构化输出形式。这个做法的考虑是即使面对恶意输入也要让下游系统拿到的是一个可安全处理的数据结构而不是一块不可控的文本。对抗性输入这块是Agent安全的基本盘不能省。5. 考虑边界与限制什么场景不适合无Tool Calling方案5.1 需要外部实时数据的场景果断放弃这个方案有个与生俱来的边界不调用任何外部工具意味着模型只能依靠内部知识完成推理。如果你的Agent核心任务需要查询实时价格、数据库状态、第三方API数据这个方案完全不适用。强行“无Tool”只会让Agent编造一个看似合理的答案在业务中这是不可接受的。不过有一条折中路径在Agent外部做好数据准备把查询结果塞进上下文再交给LLM处理。这种“外部查询LLM整合”的方式本质上仍然是先取数后推理不具备实时互动性但可以覆盖大量准实时业务场景。要不要更进一步引入真正的Tool Calling取决于实时性要求有多硬。5.2 多步骤操作类任务无Tool方案难胜任另一个明显的短板是多步骤操作执行比如“帮我订机票并发送确认邮件”。这要求Agent不仅能解析目的还要按流程触发动作、处理中间状态。这种任务里的“动作”本质上就是工具调用靠纯LLM做状态管理和协同是自讨苦吃。我曾试过“用文本模拟操作”的方式让模型输出一个操作序列再由外层代码逐条执行。效果只能说勉强可用一旦某个操作失败整个状态机就开始混乱。这个方向后来被我放弃了。如果业务需要真正的多工具协同自动化建议去找成熟的Agent编排框架或自行实现健壮的工具调用层。6. 最终实现效果与实际体验压测数据上面已经交叉提过这里统一整理一份实测体验供参考。指标初版纯Prompt约束当前版三重保险路由合法JSON率72.3%98.7%语义抽取准确率人工复核78.1%91.4%平均单次响应耗时1.8s2.1s纠错轮次平均1.2次0.3次每万次调用成本基准约1.6倍基准合法JSON率从72%提到98.7%是三重保险叠加的结果准确率提升则主要得益于Schema字段设计和提示词的迭代。响应耗时增加的0.3秒来自路由分类和字段校验是值得付出的代价。成本变高的原因主要是多了意图分类这一次调用和偶尔的纠错轮次但整体可控。我要特别强调一点98.7%的合规率里最终真正落在“无可执行结果”状态的比例不到1%。这个数据对我来说才是最重要的——Agent不是“偶尔能给漂亮结果”的玩具而是每一次调用都有稳定退路的生产组件。7. 落笔后的几点真实心得这个项目做下来最大的认知转变是“不要把Agent当成魔法而要当成工程”。模型的聪明程度确实一直在涨但真正让一个Agent变得可用的是那些不性感的工程细节Schema怎么设计、路由怎么容错、失败怎么兜底、成本怎么治理。没有这些模型的聪明只会变成不可控的聪明。如果让我给准备入坑Agent开发的同行一句建议那就是先从“无Tool”结构开始。它逼迫你把系统的骨架打牢把结构化输出和校验机制做扎实。等这些基础稳固了再往里加工具调用、加知识库记忆都是延展而非重构。反过来从复杂框架入手大概率前两周都在框架本身的坑里打转很少能真正沉淀出属于自己的方法论。最后再分享一个小技巧每次修改Agent逻辑前先用脚本记录当前版本的全部提示词和Schema并跑一遍黄金样本集存为基线。两周后你会发现版本历史比你的记忆可靠得多回滚的时候更是救命。这个习惯我一直沿用强烈推荐。
2. 核心细节解析与实操要点2.1 结构化输出的三重保险既然标题定了“无 Tool Calling”那结构化输出就全靠约束了。我的第一版实现就是纯靠“提示词好话好说”结果效果非常感人——五个样本里三个都能给出合法JSON但只要句子一长、业务字段一多总有模型在中间某处“放飞自我”。所以后来我把结构化输出做成三层保险叠加起来用第一层是系统提示词中的Schema约束。这一步不是把JSON Schema原样丢给模型就完事儿要配合解释说明。我用的模板大概是你的输出必须是一个JSON对象严格匹配以下JSON Schema。 不要输出任何额外文字、代码块标记如json、注释。 如果某个字段没有可用信息使用null填充不要编造。Schema本身尽量精简字段名用语义化命名Enum字段给出可读性强的取值注释。模型毕竟不是机器它对Schema的理解是靠“语义”建立的字段写得越直白约束越有效。第二层是响应解析与结构校验。这一层必须在代码里做不能偷懒。拿到LLM返回的字符串后我用Pydantic定义跟Schema对应的模型再调用model_validate_json()做解析。这个库好用就好在解析不通过时它会告诉我具体是哪个字段、哪种类型对不上定位错误非常方便。每次都把解析失败的内容连同报错信息一起原样记录下来后续做“自纠错”时要用。第三层是自动重试与自我修正。如果解析失败我不会直接报错给用户而是把失败原因和原始响应拼到一条新消息里让模型重写。这条“纠错提示词”我写得很有讲究不是简单说“你错了再试一次”而是明确告诉它哪里错了、期望什么你上一次的输出不合规。以下是具体问题和期望修正方向 - 原始输出[粘贴模型输出] - 校验报错[粘贴Pydantic报错] - 修正要求重新输出完整的JSON对象 确保所有字段符合Schema数组字段至少包含0个元素 枚举字段严格按照给定值之一输出。实测下来执行一次纠错之后成功率能从70%左右拉到接近96%第二轮的纠错空间极大但必须配合重试上限防止陷入死循环。我把重试上限设为2次超过就返回一个带fallback标记的结果宁可让业务层看到“本次Agent处理失败”也不能让脏数据混入下游。2.2 提示词里暗藏的门道行业内有个说法叫“prompt engineering 已经被 LLM 能力增长冲淡了”但那是针对通用问答场景用在Agent上根本不成立。Agent的提示词是逻辑的一部分是真正参与运算的程序代码设计得不好再强的模型也做不稳。我的提示词遵循三个原则原则一给例子而且要放在描述后面紧跟的位置。Few-shot示例不是摆设模型对“例子的格式”的敏感程度远高于对“文字的规则”。给两个对比强烈的示例一个是完全合规的输出一个是带轻微瑕疵比如在JSON后面加了句废话的输出并显式标注后者为什么不合格。这比写十行“不许输出废话”都管用。原则二明确的任务边界比任务本身更容易被遵守。很多人写提示词只告诉模型要干什么不告诉它不干什么。我会把“禁止行为”单独列出来不要推测缺失信息、不要补全未提供的上下文、不要输出自然语言解释。重点来了——这些“禁止”不用祈使句堆砌而是转换成一个“自检清单”让模型在输出前先过一遍。原则三让模型扮演“解析器”而不是“创造者”。我对模型说你的职责不是基于你的知识创作内容而是把用户提供的原始材料做一个“重新整理”。这个身份设定极大地减少了模型自由发挥的倾向性。凡是要模型提取信息的任务它一旦以为自己是“搜索引擎文案大师”你就等着在JSON里读到它自己编出来的知识吧。2.3 路由层设计怎么让一个Agent干多种活“通用Agent”意味着不能给每个业务场景单独开发一套模型和提示词而是靠一个路由层把不同请求分发给不同的“任务处理器”。我的做法非常克制没有上多Agent框架而是用一个轻量级“意图分类器”做内部路由。具体流程是用户输入进来后先由LLM判定这条输入属于哪个领域/意图输出一个简短的结构化标签比如{intent: summary}然后代码根据标签挑选对应的处理模板。这个“意图分类”本身也只调一次LLM而且模型极擅长这种低难度分类任务实测准确率在96%以上。这里的核心考量是不要让路由判断承担太多信息压缩的职责。意图标签只负责“选择路径”不负责“承载结果”业务细节全部留给后续的处理流程。每个处理路径共享同一个输出规范化模块所以在行为上保持一致只有处理逻辑的差异没有输出风格的风险。有一个坑值得提醒意图标签不要设计太细。我有一次把意图分到12个类别模型开始频繁误判两个相似分类之间来回摇摆。收敛到5个主类、每个主类下面再用分支处理子场景之后稳定性好了很多。意图分类必须保持“人类也能一眼区分”的粒度凡是连人都不容易分清的两个类别模型大概率也分不好。2.4 记忆与上下文管理的取舍这个Agent是“通用”且“无工具”的这就意味着它处理的是单轮内的复杂任务而不是长期对话记忆。说白了整个Agent的能力核心是“在有限上下文里把事一次办好”不依赖长期记忆模块。但我还是给短期上下文做了精心管理否则模型很容易在长输入下“忘前头”。上下文裁剪的策略是“三段式”最近3轮对话保留完整原文更早的内容压缩成摘要压缩摘要的字段格式也是JSON。这个摘要由模型在每一轮结束时自动生成存成固定结构新的一轮开始时把它插回上下文。看似简单效果却出乎意料的好——模型的“记忆感”明显增强在连续多轮的结构化抽取任务里字段一致性高了很多。没有用向量数据库做检索记忆这是有意为之。“通用Agent”的定位不是知识问答机器人大多数输入的知识密度并不高向量检索增加的延迟和不确定性反而大于收益。在信息需求确凿的场景比如文档解析、信息抽取“直接塞进上下文”比“检索再召回”更快更准。结论是记忆不是越复杂越好要先想想你的任务到底需不需要记忆。3. 实操过程与核心环节实现3.1 技术栈选型与原因动手之前我先把技术栈定下来避免写到一半被底层库折腾。我的组合是Python LangChain仅用基础组件 Pydantic OpenAI SDK没有引入重型编排框架后面细说为什么。模型选择上我用的是通用对话模型如GPT-4o-mini级别而非代码生成模型。原因在于代码生成模型容易把输出格式带偏成“给程序员看的东西”而通用模型在“模拟人类填写表格”的场景下表现得更加自然。为了控制成本和延迟我还在长任务上使用了异步调用的方式并发处理多个请求这在后面小节展开讲。LangChain在这个项目里只用来管理Prompt模板和输出解析器不用它的Agent执行框架。原因是LangChain的Agent抽象封装了太多逻辑出了问题排查起来像是在解套娃而我们要做的是一个“流程极简、行为透明”的系统。一条处理链路输入 → 意图分类 → 任务处理 → 结构校验 → 输出修正 → 返回每一步都可观测、可单独调试这对“通用Agent”的可维护性至关重要。Pydantic的价值在整套流程里被彻底放大了。我定义的任务模型都继承了BaseModel每个字段写上详尽的Field(description...)。模型在“结构化抽取”场景下对字段描述的理解程度直接决定了抽取质量这相当于免费给模型塞了个语义提示。3.2 核心代码结构详解下面这段代码是我整个Agent骨架的浓缩。结构很简单但每个函数都承担着一个不可省略的职责。import json from typing import Any, Callable from pydantic import BaseModel, ValidationError class AgentInput(BaseModel): raw_text: str user_intent: str | None None class AgentOutput(BaseModel): intent: str data: dict[str, Any] confidence: float fallback: bool False class StructuredAgent: def __init__(self, llm, router_prompt, task_prompts: dict[str, str], max_retries: int 2): self.llm llm self.router_prompt router_prompt self.task_prompts task_prompts self.max_retries max_retries def _classify_intent(self, raw_text: str) - str: # 轻量意图分类输出固定为{intent: xxx} resp self.llm.chat( messages[ {role: system, content: self.router_prompt}, {role: user, content: raw_text}, ], response_format{type: json_object}, ) parsed json.loads(resp) return parsed[intent] def _run_task(self, intent: str, raw_text: str) - str: prompt self.task_prompts[intent] resp self.llm.chat( messages[ {role: system, content: prompt}, {role: user, content: raw_text}, ], response_format{type: json_object}, ) return resp def _validate(self, intent: str, raw_json: str) - AgentOutput: # 此处简化处理实际应针对每种intent做字段级校验 parsed json.loads(raw_json) return AgentOutput( intentintent, dataparsed, confidenceparsed.get(confidence, 0.8), ) def run(self, raw_text: str) - AgentOutput: intent self._classify_intent(raw_text) last_error None for attempt in range(self.max_retries 1): raw_resp self._run_task(intent, raw_text) try: return self._validate(intent, raw_resp) except (json.JSONDecodeError, ValidationError) as e: last_error str(e) # 把错误信息回喂给模型 raw_text ( f本次输出非法错误原因{last_error}。 f原始输出{raw_resp}。请严格按照schema重新输出完整JSON。 ) return AgentOutput( intentintent, data{}, confidence0.0, fallbackTrue )这段代码是“能用”的程度但不是我最终线上跑的版本。生产版本多做了两件事一是引入异步并发处理用asyncio.gather一次处理多个用户请求二是给每个请求加了超时控制和异常隔离某个请求的失败不会拖垮整批任务。3.3 并发与性能一个Agent扛住高并发请求热词里有人搜“AI Agent怎么扛并发”恰好我在这块做过压测可以分享一下粗糙经验。单机部署下基于LLM的Agent瓶颈不在代码而在两类资源模型API的速率限制、以及并发请求时的上下文内存占用。第一个瓶颈处理方式是令牌桶限流加指数退避重试。API返回429或连接超时我没有立刻报错而是做一个简单的退避等待再试退避的时间间隔按照0.5s * 2^n递增最大不超过8秒。实测这个策略能把“瞬时高峰请求”稳稳送进API而不会触发封禁。第二个瓶颈处理方式是控制单个请求的Token预算。我用tiktoken在进入系统前先估算总Token数超过预设阈值的输入先做分段处理再合并。这个做法对成本的影响也很大因为结构化输出往往比普通对话更耗Token。并发压测数据上我用一个8核16G的轻量云主机跑同步版本QPS稳定在3.5左右改成异步版本后提升到11左右。瓶颈确实在LLM响应时长代码本身的耗时占比很小这也是为什么我说“Agent扛并发”的关键不在写代码而在合理管理调用策略。3.4 模型选择与降本增效有关“Agent开发用什么模型”这个问题小红书上的回答真是花里胡哨。实际上我的结论很简单小任务用小模型大任务用大模型不要一套模型打天下。意图分类这种低复杂度任务用mini级别就够又快又便宜。内容抽取、复杂推理任务才切到标准模型。成本上我按“每万次请求”算过账全用大模型跑成本约是“大小模型混合调度”的4倍而准确率差异不到1个百分点。所以做通用Agent时模型分级调度是降本的第一杠杆。还要提一嘴结构化输出模式。最新模型已经原生支持JSON响应格式这让输出合法JSON的概率提高了不少比靠提示词硬掰可靠。但这个能力只解决了“语法合规”没有解决“语义准确”业务字段的抽取质量还是得靠任务提示词。不要以为开了JSON模式就万事大吉做字段级校验永远是最后一道防线。4. 常见问题与排查技巧实录4.1 模型输出总是差一口气如何定位“脏”字段拿到不合规JSON后第一步不是改提示词而是得分清楚“脏”在语法层还是语义层。语法层问题是JSON本身不合法逗号多了一个、引号缺了一个。这类问题用Pydantic的报错信息就能定位一般加一轮纠错就能清掉。语义层问题才是大头。模型的输出是合法JSON但内容不对比如字段值张冠李戴、数组里混进了多余元素。这没法靠校验器发现只能人工抽查。我常用的办法是构建一个小型“黄金样本集”大约50条典型输入每轮改动Prompt后都跑一遍这个样本集人工对比抽取结果。虽然费时间但这是唯一能守住质量底线的办法。另一个排查技巧是让模型“自解释”。不是让它在正式输出里加解释而是在调试模式下额外生成一段“你为什么提取这个值”的说明。模型说得清楚通常说明它理解了任务一旦语焉不详大概率是猜的回去改提示词。这个小技巧帮我精确绕开过好几个糊弄场景。4.2 意图分类误判时的兜底策略再好的路由方案也有误判的时候尤其在用户输入模棱两可时。我给Agent设了一条兜底规则当意图分类置信度低于阈值时不直接走任何任务分支而是进入“澄清模式”。澄清模式下的输出也是一个JSON包含一个clarifying_question字段由外层代码决定是直接展示给用户还是走默认分支。“澄清模式”不是让模型反复问用户“你是什么意思”那样体验太烂。我只允许Aladdin一级澄清最多问一个最可能区分意图的问题。例如意图同时命中“摘要”和“翻译”时问一句“你希望我为你翻译还是概括这段内容”已经足够。一级澄清经费别用多用多就成了客服机器人。兜底策略的第二层是 “默认处理器”。如果意图分类模型连续三次给出低置信度我直接把这个请求送到一个“通用结构化转换器”它不绑定任何特定业务场景只负责把用户原始输入转换成一份“泛信息结构”标题、要点、原文摘录保证用户至少拿到一个可用的结果而不是一个冷冰冰的报错。4.3 长文本输入导致的上下文截断这个坑我踩得最惨的一次是处理一份长达两万字的合同扫描文本时Agent输出内容中间突然开始胡言乱语最后还返回了一个不完整的JSON。排查后确认问题的根源是上下文超出了模型的窗口限制模型只能看到前一段后面的业务关键信息全丢了。解决思路不是简单截断而是给长文本做了“分块逐块提取合并”的处理链。首先把长文本按段落或语义边界切分成多个块每块控制在模型上下文窗口的一半以内。每个块单独跑一次结构化抽取得到该块的局部结果。再把所有局部结果汇总让模型做二次融合生成一份统一结构的输出。这个“分而治之”方案听起来冗余实际效果非常稳定——单次抽取的准确率从截断时的不到50%提升到了稳定在88%以上。代价是API调用次数变多所以只在输入长度超过阈值时才启用分段模式。4.4 结构化输出与业务场景的匹配度纠偏“结构化Agent”最容易出现的问题是技术上输出格式完美但业务上毫无用处。比如一个客户投诉分类任务模型输出了一大堆通用字段标题、摘要、情感倾向但业务方真正需要的“投诉类型”、“责任部门”、“紧急程度”反而没提取出来。这类问题不是模型笨而是Schema设计脱离了业务。我的修正办法是在设计Schema前先跟业务方确定“这个字段如果为空业务还跑不跑得起来”。凡是“为空就跑不起来”的字段必须让它成为模型抽取的强制关注点在提示词里单独加粗说明。凡是“只有最好有”的字段一律放到可选字段组不让它们分散模型注意力。Schema的字段数量建议控制在8到12个超过这个范围单次抽取的准确率会开始明显下降。字段命名也同样重要。我坚持用业务术语命名而不是通用术语。比如电商场景里“退款原因”绝不要命名为“reason”因为模型对这种宽泛字段的处理往往是模糊的。把字段名写成“customer_refund_reason”加上示例值之后模型的抽取质量会有肉眼可见的提升。4.5 成本失控的预警与治理无Tool Calling方案里最容易成本失控的环节就是“自纠错”。每多一次纠错就多一轮API调用而纠错轮次的输出Token往往比首轮更长它要复述修正日志。我曾看到一次纠错把单请求的Token消耗拉到首轮的3倍必须设上限。治理手段是三层第一层是总轮次上限上面代码里的max_retries写死不超过2第二层是Token上限单次请求如果预计超过预设阈值直接转为分段处理而不是让模型硬啃第三层是告警实时监控纠错率当一个小时内的纠错率超过10%就触发警告提示去检查提示词稳定性。纠错率突然飙升往往是上游输出来源变了比如新版本模型上线早发现比晚补救强太多。4.6 安全守护Agent输出可信度如何把控Agent的输出不是给人看的文案而是直接参与业务逻辑的数据所以可信度是硬指标。我的系统里专门加了一个confidence信号由模型在输出时自评。这个自评能力在常规任务中并不可靠所以我会在业务层再做一道交叉验证凡是置信度低于0.7的结果一律转入人工审核队列。另外当系统检测到用户输入里含有诱导性指令比如让Agent忽略系统提示词、改变输出角色等时我不会直接拒绝而是把结果标记为“low_trust”并保持结构化输出形式。这个做法的考虑是即使面对恶意输入也要让下游系统拿到的是一个可安全处理的数据结构而不是一块不可控的文本。对抗性输入这块是Agent安全的基本盘不能省。5. 考虑边界与限制什么场景不适合无Tool Calling方案5.1 需要外部实时数据的场景果断放弃这个方案有个与生俱来的边界不调用任何外部工具意味着模型只能依靠内部知识完成推理。如果你的Agent核心任务需要查询实时价格、数据库状态、第三方API数据这个方案完全不适用。强行“无Tool”只会让Agent编造一个看似合理的答案在业务中这是不可接受的。不过有一条折中路径在Agent外部做好数据准备把查询结果塞进上下文再交给LLM处理。这种“外部查询LLM整合”的方式本质上仍然是先取数后推理不具备实时互动性但可以覆盖大量准实时业务场景。要不要更进一步引入真正的Tool Calling取决于实时性要求有多硬。5.2 多步骤操作类任务无Tool方案难胜任另一个明显的短板是多步骤操作执行比如“帮我订机票并发送确认邮件”。这要求Agent不仅能解析目的还要按流程触发动作、处理中间状态。这种任务里的“动作”本质上就是工具调用靠纯LLM做状态管理和协同是自讨苦吃。我曾试过“用文本模拟操作”的方式让模型输出一个操作序列再由外层代码逐条执行。效果只能说勉强可用一旦某个操作失败整个状态机就开始混乱。这个方向后来被我放弃了。如果业务需要真正的多工具协同自动化建议去找成熟的Agent编排框架或自行实现健壮的工具调用层。6. 最终实现效果与实际体验压测数据上面已经交叉提过这里统一整理一份实测体验供参考。指标初版纯Prompt约束当前版三重保险路由合法JSON率72.3%98.7%语义抽取准确率人工复核78.1%91.4%平均单次响应耗时1.8s2.1s纠错轮次平均1.2次0.3次每万次调用成本基准约1.6倍基准合法JSON率从72%提到98.7%是三重保险叠加的结果准确率提升则主要得益于Schema字段设计和提示词的迭代。响应耗时增加的0.3秒来自路由分类和字段校验是值得付出的代价。成本变高的原因主要是多了意图分类这一次调用和偶尔的纠错轮次但整体可控。我要特别强调一点98.7%的合规率里最终真正落在“无可执行结果”状态的比例不到1%。这个数据对我来说才是最重要的——Agent不是“偶尔能给漂亮结果”的玩具而是每一次调用都有稳定退路的生产组件。7. 落笔后的几点真实心得这个项目做下来最大的认知转变是“不要把Agent当成魔法而要当成工程”。模型的聪明程度确实一直在涨但真正让一个Agent变得可用的是那些不性感的工程细节Schema怎么设计、路由怎么容错、失败怎么兜底、成本怎么治理。没有这些模型的聪明只会变成不可控的聪明。如果让我给准备入坑Agent开发的同行一句建议那就是先从“无Tool”结构开始。它逼迫你把系统的骨架打牢把结构化输出和校验机制做扎实。等这些基础稳固了再往里加工具调用、加知识库记忆都是延展而非重构。反过来从复杂框架入手大概率前两周都在框架本身的坑里打转很少能真正沉淀出属于自己的方法论。最后再分享一个小技巧每次修改Agent逻辑前先用脚本记录当前版本的全部提示词和Schema并跑一遍黄金样本集存为基线。两周后你会发现版本历史比你的记忆可靠得多回滚的时候更是救命。这个习惯我一直沿用强烈推荐。
