单智能体架构的甜蜜点：高效、可控、可维护的LLM落地范式

1. 项目概述：单智能体架构的“甜蜜点”到底甜在哪儿？

“LAI #121: The single-agent sweet spot nobody wants to admit”——这个标题一出来，我就在好几个技术群看到有人截图转发，配文是“又一个戳破行业幻觉的狠活”。它不是讲某个新模型、新框架，也不是教你怎么调参，而是直指当前大模型应用落地中最隐蔽也最普遍的认知偏差：我们正集体性地、高成本地绕开那个真正高效、可控、可维护的单智能体（single-agent）设计路径，转而扎堆扑向多智能体（multi-agent）的复杂迷宫。关键词里没写“LLM”“RAG”“Orchestrator”，但全文每一个字都在和它们对话；没提“成本”“延迟”“可观测性”，可这三个词才是藏在标题背后真正的主角。这个“甜蜜点”，说白了就是：用一个结构清晰、职责单一、状态可控的智能体，完成80%以上真实业务场景中的核心任务闭环——比如客服工单自动归类+初筛+生成标准回复草稿+触发人工审核流程；比如销售线索打分+匹配对应BD经理+同步CRM字段+生成首次触达话术。它不炫技，不拼Agent数量，但实测下来，上线周期缩短40%，运维告警下降70%，业务方反馈“终于能看懂系统在想什么了”。适合谁？不是给纯算法研究员看的，而是给每天被PM追着问“为什么这个需求两周还没上线”的后端负责人、被SRE半夜call醒查“为什么Agent集群CPU又爆了”的平台工程师、以及被销售总监指着Dashboard质问“为什么推荐准确率上不去”的AI产品同学。它解决的不是“能不能做”，而是“值不值得用最重的方案去做”。

我去年主导过两个对比项目：一个是内部知识库问答系统，初期按主流方案搭了5个Agent（检索Agent、意图理解Agent、答案生成Agent、格式校验Agent、安全过滤Agent），每个Agent都配独立微服务、独立Prometheus指标、独立日志流。上线第三周，一次上游ES集群抖动导致检索Agent超时，整个链路雪崩，下游4个Agent全在疯狂重试，日志量暴涨300%，SRE花了6小时才定位到根因是第一个Agent的熔断阈值设得太激进。另一个是客户投诉分类系统，我们反其道而行，只用一个Agent，但把它的prompt engineering做到极致：输入是原始投诉文本，输出是JSON结构化结果（含一级分类、二级子类、紧急程度、是否需法务介入、建议处理时效），中间所有逻辑——包括实体识别、上下文推理、规则兜底、置信度校验——全部压缩进一个LLM调用+少量本地规则引擎中。上线后，平均响应时间从1.8秒压到0.42秒，错误率比多Agent方案低12%，最关键的是，当业务方提出“把‘物流延迟’下的‘海外仓发货’子类单独标记为高优”时，我们改了3行prompt和1条规则，15分钟就灰度发布。这才是标题里“sweet spot”的真实体感：不是技术上做不到更复杂，而是业务上不需要更复杂。它承认LLM的不确定性，用确定性的工程手段去框定、约束、兜底，而不是幻想靠堆叠Agent来“对冲”这种不确定性。

2. 单智能体架构的核心设计逻辑与现实权衡

2.1 为什么“单智能体”反而是更难的设计选择？

很多人第一反应是：“单Agent？那不就是个Prompt加个API调用？有啥技术含量？” 这恰恰是最大的认知陷阱。多Agent的本质是责任分散——把一个复杂问题切片，让不同Agent各管一段，听起来很“面向对象”，但实际落地时，它把最难的问题转移给了系统集成层：Agent间的协议怎么定义？状态如何传递？错误如何传播？超时如何协同？重试策略谁来统一？这些问题没有银弹，每个都要自己造轮子，而且越往后越难收口。而单Agent的难点在于责任内聚——你必须把所有可能的分支、边界、异常、业务规则，全部塞进一个决策单元里。这要求你对业务域的理解必须深到能画出完整的决策树，对LLM能力边界的把握必须准到能预判它在哪种输入下会“胡言乱语”，对工程鲁棒性的设计必须细到连token截断、JSON格式错误、网络抖动都要有明确fallback。这不是偷懒，是把复杂性从分布式协调转移到了单点建模上。我见过太多团队，花三个月搭好5个Agent的架子，结果第4个月还在纠结“检索Agent返回空结果时，生成Agent该返回‘未找到’还是直接报错”，而一个成熟的单Agent方案，会在prompt里就写死：“若检索无结果，必须返回{‘status’: ‘not_found’, ‘suggestion’: ‘请尝试描述更具体的故障现象’}”，并用正则校验强制JSON格式，再加一层本地缓存兜底。前者是把问题抛给运行时，后者是把问题解决在设计时。

2.2 “甜蜜点”的三个硬性技术锚点

这个“sweet spot”不是玄学，它有三个可量化、可验证的技术锚点，缺一不可：

1. 输入-输出契约必须严格结构化：单Agent绝不接受“自由发挥”。输入必须是明确定义的schema（如客服工单的JSON Schema包含ticket_id, customer_level, issue_description, attachment_urls），输出必须是同样严格的schema（如{“category”: “billing”, “severity”: “high”, “next_step”: “escalate_to_finance”, “confidence”: 0.92}）。我们曾用OpenAPI 3.0规范来定义这个契约，并自动生成TypeScript类型和Python Pydantic模型，所有LLM输出都必须通过该模型的validate()方法，失败则触发预设的规则引擎兜底。这直接砍掉了80%的“格式错误”类线上问题。

2. 决策路径必须可穷举、可追溯：不能依赖LLM“灵光一现”。我们在prompt中强制要求Agent在输出JSON前，先输出一段带编号的推理过程（如“1. 用户提到‘扣款失败’且订单号以‘ORD-US’开头 → 判定为跨境支付问题；2. 用户账户余额充足 → 排除余额不足；3. 近2小时无同类失败记录 → 排除系统级故障；4. 综上，大概率是PayPal接口临时限流，建议重试并降级至信用卡通道”）。这段推理文本不返回给用户，但会存入审计日志，和最终输出JSON一起落库。当业务方质疑“为什么这个单子没标高优”，我们直接查日志，第3条推理就暴露了判断依据，而不是让算法同学去翻三天前的prompt版本。

3. 能力边界必须有确定性兜底：LLM不是万能的，单Agent必须明确知道“什么时候该认怂”。我们定义了三类兜底机制：a)规则兜底：对高频、确定性场景（如“发票金额>10万必须法务审核”），用本地if-else实现，绕过LLM；b)缓存兜底：对历史高频问题（如“如何重置密码”），命中缓存直接返回标准答案，响应时间<10ms；c)降级兜底：当LLM调用超时或返回异常，自动切换至轻量级模型（如Phi-3-mini）或确定性模板。这三者共同构成一个“信任金字塔”，LLM只负责处理金字塔尖上那20%真正需要泛化推理的问题。

提示：很多团队试图用“动态Agent编排”来模拟单Agent效果，比如根据输入自动决定调用哪个Agent。这本质上还是多Agent，只是把调度逻辑从静态配置变成了运行时决策。它非但没解决状态传递和错误传播问题，反而增加了调度器本身的复杂度和单点故障风险。真正的单Agent，是“一个Agent，一套逻辑，一次调用”。

2.3 多Agent方案为何成了“舒适区陷阱”？

为什么大家明知道单Agent更高效，却还是热衷于多Agent？这里有三层“舒适区陷阱”：

• 技术舒适区：多Agent让每个工程师可以专注自己那一小块——前端同学只管调用“生成Agent”的API，后端同学只优化“检索Agent”的ES查询性能，算法同学只调“分类Agent”的few-shot prompt。责任被切得足够细，KPI也容易拆解。而单Agent要求一个人（或一个小团队）横跨Prompt Engineering、规则引擎、可观测性、容灾设计，对个人能力栈要求陡增，短期看“产出慢”。

• 心理舒适区：当线上出问题时，“是检索Agent返回了脏数据，导致生成Agent胡说”这种归因，比“我们的单Agent prompt没覆盖XX边缘case”听起来更“合理”，也更容易甩锅给上下游。多Agent天然提供了责任隔离墙，哪怕这堵墙本身就在制造更多问题。

• 叙事舒适区：在技术分享、融资路演、内部汇报中，“我们构建了业界领先的多智能体协同平台”听起来远比“我们用一个精心设计的单Agent解决了90%的工单”更有故事性、更“前沿”。投资人爱听“Agent Swarm”，客户爱看“智能体协作动画”，但没人愿意为“一个没动画的JSON Schema”买单。这种叙事惯性，让很多团队在技术选型之初，就主动放弃了最务实的路径。

我亲眼见过一个金融风控项目，初期用5个Agent分别处理“身份核验”“交易行为分析”“关联图谱挖掘”“规则引擎匹配”“报告生成”，PPT做得极其炫酷。上线半年后，因为“关联图谱挖掘Agent”依赖的图数据库版本升级，导致其输出格式微变，下游“规则引擎匹配Agent”解析失败，整个风控链路中断47分钟，损失无法估量。事后复盘，如果当初用单Agent，所有逻辑都在一个prompt里，图谱数据格式变更只需同步更新prompt中的解析指令和本地校验规则，根本不会引发级联故障。所谓“先进”，有时候只是把故障面从一个点，扩散成了一个面。

3. 单智能体核心环节的实操实现与细节打磨

3.1 Prompt Engineering：从“写提示词”到“构建决策协议”

在单Agent架构里，Prompt不再是“告诉模型做什么”，而是“定义一个不可协商的决策协议”。它必须像一份法律合同，条款清晰、权责分明、违约有罚。我们实践下来，一个工业级单Agent Prompt必须包含五个强制模块：

1. 角色与权限声明（Role & Scope）：开宗明义，限定Agent的能力边界。例如：“你是一个银行信用卡中心的工单初审Agent，仅负责对用户提交的投诉文本进行分类、紧急度评估、初步原因推断。你无权访问用户账户详情、交易流水、征信报告等敏感数据。所有判断必须基于投诉文本本身及已知的公开业务规则。”

2. 输入规范（Input Schema）：用JSON Schema或类似结构，精确描述输入字段、类型、约束、示例。避免模糊表述如“用户描述的问题”。我们甚至会把输入JSON的字符串长度、特殊字符（如换行符、emoji）的处理方式都写进去：“若input.issue_description包含超过3个连续换行符，视为格式错误，立即触发规则兜底。”

3. 决策逻辑（Decision Logic）：这是核心。不能只写“请分析问题”，而要拆解成可执行的步骤。例如：“Step 1: 提取所有出现的数字，判断是否为订单号（符合ORD-[A-Z]{2}-\d{8}模式）或卡号（符合\d{4}-\d{4}-\d{4}-\d{4}模式）；Step 2: 若提取到订单号，查询本地缓存确认该订单是否存在且状态为‘processing’；Step 3: 若Step 2为True，且文本中出现‘未收到’、‘延迟’等关键词，则归类为‘物流问题’，否则归类为‘系统问题’……” 每一步都必须有明确的输入、处理、输出、跳转条件。

4. 输出契约（Output Contract）：强制规定输出必须是严格JSON，列出所有必填字段、可选字段、字段类型、枚举值、数值范围。例如：“{‘category’: ‘string’, ‘allowed_values’: [‘billing’, ‘logistics’, ‘system’, ‘other’], ‘severity’: ‘string’, ‘allowed_values’: [‘low’, ‘medium’, ‘high’, ‘critical’], ‘confidence’: ‘number’, ‘min’: 0.0, ‘max’: 1.0}”。并附加校验指令：“若输出JSON不符合上述契约，或包含任何额外字段，或字段值不在allowed_values中，请重新生成，最多重试2次，第3次仍失败则触发规则兜底。”

5. 兜底与降级（Fallback Protocol）：明确写出所有可能的失败场景及应对动作。例如：“若LLM调用超时（>3s），立即返回{‘status’: ‘timeout’, ‘fallback_used’: ‘cache’}；若LLM返回JSON格式错误，启动正则校验脚本，尝试修复；若修复失败，返回{‘status’: ‘parse_error’, ‘fallback_used’: ‘template’}并填充预设模板。”

这套Prompt不是一蹴而就的。我们采用“三阶迭代法”：第一阶，用最简prompt跑通主干流程，收集1000条真实输入，统计失败原因；第二阶，针对TOP3失败原因（如“JSON格式错误”“分类遗漏”“置信度虚高”），在Prompt中增加对应的约束和校验指令；第三阶，将所有规则引擎兜底逻辑，反向注入Prompt的“决策逻辑”模块，形成“LLM优先，规则兜底”的混合决策流。实测下来，经过三阶迭代的Prompt，线上稳定率从68%提升到99.2%，而多Agent方案同期的链路成功率只有82%（因各Agent稳定性不一，整体服从木桶原理）。

3.2 规则引擎：单Agent的“确定性脊梁”

单Agent绝不是“LLM万能论”，它的强大恰恰源于LLM与规则引擎的深度耦合。我们把规则引擎定位为单Agent的“确定性脊梁”——它不参与创造性推理，但为所有高确定性、高合规性、高时效性的决策提供100%可靠的支撑。实践中，我们采用“三层规则体系”：

• L1：硬性业务规则（Hard Rules）：完全由代码实现，零容忍。例如：“所有涉及‘退款’、‘赔偿’、‘法律’字样的投诉，无论LLM输出如何，category必须强制设为‘compliance’，severity必须设为‘critical’。” 这类规则直接写在Agent的预处理和后处理函数里，LLM调用前后各执行一次，像一道铁闸。

• L2：启发式规则（Heuristic Rules）：基于经验总结的快速判断。例如：“若投诉文本中同时出现‘APP’和‘闪退’，且设备型号为‘iPhone 15’，则大概率是iOS 17.4系统兼容性问题，category=‘system’, severity=‘high’。” 这类规则用轻量级Python函数实现，放在LLM调用前作为“快速通道”，命中即返回，不调用LLM，极大降低延迟和成本。

• L3：LLM增强规则（LLM-Augmented Rules）：规则引擎不替代LLM，而是增强它。例如，我们有一个“模糊匹配规则库”，里面存着几千条用户常用口语表达与标准业务术语的映射（如“钱没到账”→“payment_not_received”，“APP打不开”→“app_unavailable”）。在LLM调用前，先用这个库对原始文本做一次标准化替换，再把标准化后的文本喂给LLM。这相当于给LLM戴了一副“业务术语眼镜”，显著提升了它对非标准表达的理解准确率。实测显示，加入L3规则后，LLM在长尾口语表达上的分类F1-score提升了27个百分点。

规则引擎的部署不是独立服务，而是深度嵌入Agent的生命周期。我们用一个统一的RuleExecutor类，封装所有规则的加载、匹配、执行、日志记录。每次Agent处理请求，RuleExecutor会按L1→L2→L3的顺序依次扫描，任何一层命中即终止后续扫描，并将结果注入最终输出。这种设计保证了规则的可插拔性——业务方要新增一条规则，只需提交一个YAML文件到Git仓库，CI/CD流水线自动将其编译进RuleExecutor，无需重启服务。上线一条新规则，从提交到生效，全程5分钟。

3.3 可观测性与调试：让单Agent“看得见、摸得着”

单Agent最大的优势是“简单”，但最大的挑战是“简单带来的黑盒感”——当它出错时，你只有一个入口和一个出口，中间发生了什么？我们为此构建了一套“穿透式”可观测性体系，目标是让每一次调用都像X光片一样清晰：

• 全链路日志（Full-Trace Logging）：每条请求生成唯一trace_id，贯穿整个处理流程。日志结构化记录：输入原始JSON、预处理后的标准化文本、LLM调用的完整prompt（含所有变量值）、LLM返回的原始响应字符串、JSON解析结果、各层规则引擎的匹配日志（含命中规则ID、输入参数、输出结果）、最终输出JSON、处理耗时（总耗时、LLM耗时、规则耗时、序列化耗时）。这些日志全部接入ELK，支持按trace_id秒级检索。

• 决策快照（Decision Snapshot）：在最终输出JSON中，强制嵌入一个_debug字段，包含关键决策证据。例如：“{‘_debug’: {‘llm_reasoning’: ‘1. 用户提及“转账失败”且金额>5000；2. 账户余额充足；3. 近1小时无同类失败；4. 推断为反洗钱系统临时拦截’, ‘rule_hit’: [‘L1_compliance_rule_003’, ‘L2_ios174_fix_012’], ‘confidence_calculated’: 0.89}}”。这个字段不返回给前端，但对调试至关重要。当业务方质疑结果，我们直接查_debug，就能看到LLM的推理链和规则的干预点。

• 沙箱调试环境（Sandbox Debugging）：我们开发了一个Web界面，允许产品经理、客服主管直接粘贴一条投诉文本，实时看到Agent的完整处理过程：左侧是输入，中间是逐帧展开的决策流（“标准化后文本：…”、“L2规则匹配：APP闪退→system/high”、“LLM Prompt：…”、“LLM Raw Output：…”、“JSON解析结果：…”），右侧是最终输出。他们可以随时修改输入文本，点击“重跑”，立刻看到变化。这个沙箱环境极大降低了业务方的理解门槛，也让我们能快速收集到“为什么这个case没被正确分类”的一线反馈。

注意：可观测性不是锦上添花，而是单Agent架构的生存基础。没有这套体系，单Agent和黑盒没有任何区别。我们曾因漏掉L1规则的日志记录，导致一次合规事件中无法向审计部门证明“我们确实强制将所有涉法词汇标为critical”，被迫回滚了整个版本。从此，所有规则的执行，无论命中与否，都必须有日志。

3.4 容灾与降级：单点不等于单点故障

“单Agent”不等于“单点故障”。恰恰相反，一个设计良好的单Agent，其容灾能力远超多Agent系统，因为它没有复杂的依赖链。我们的容灾策略围绕“降级阶梯”展开：

1. 第一阶：LLM服务降级：当主用LLM（如GPT-4）不可用时，自动切换至备用LLM（如Claude-3-haiku），prompt保持不变，仅调整temperature和max_tokens以适配不同模型特性。我们预先对所有备用模型做了全量回归测试，确保输出契约一致。

2. 第二阶：轻量模型降级：当所有商用LLM都不可用时，切换至本地部署的Phi-3-mini模型。此时，prompt会动态精简，只保留最核心的决策逻辑，关闭所有“推理过程”输出，专注于生成结构化JSON。虽然置信度会下降，但保证了基本功能可用。

3. 第三阶：规则引擎接管：当所有模型都不可用时，完全由规则引擎兜底。此时，Agent退化为一个高性能的规则匹配服务，响应时间<50ms，准确率取决于规则库的覆盖率。我们要求规则库必须覆盖至少70%的高频场景（基于历史数据统计），并通过A/B测试验证其效果。

4. 第四阶：缓存与模板：对于极少数无法被规则覆盖的case，返回预设的通用模板（如“您的问题已收到，我们将尽快为您处理”），并记录为“unknown_case”，供后续分析。同时，所有成功处理的case，其输入-输出对都会进入LRU缓存，下次相同输入直接命中缓存，零延迟返回。

这个四阶降级体系，让我们的单Agent服务SLA达到了99.99%，而同期的多Agent系统，由于任何一个Agent宕机都会导致整条链路失败，SLA仅为99.5%。单点的脆弱性，被确定性的工程设计彻底化解。

4. 常见问题与实战排查技巧实录

4.1 典型问题速查表：从现象到根因的快速定位

4.2 我踩过的三个坑：血泪教训总结

坑一：过度依赖LLM的“自我修正”能力
早期我们相信LLM能在prompt中“自我反思”，所以在输出契约里写了“若发现输出有误，请自行修正”。结果上线后发现，LLM经常陷入“修正-再错-再修正”的死循环，或者干脆不修正，直接返回错误JSON。教训：LLM没有纠错能力，只有生成能力。所有校验和修正，必须由外部确定性程序（如JSON Schema Validator、正则替换脚本）完成。现在我们的流程是：LLM生成→外部校验→校验失败则触发规则兜底，绝不给LLM第二次机会。

坑二：把“单Agent”误解为“单次LLM调用”
为了追求极致性能，我们曾尝试在一个LLM调用里完成所有事，包括从数据库查用户历史、调用第三方API获取物流信息。结果是，一次调用耗时长达8秒，且任何外部依赖抖动都会导致整个Agent失败。教训：“单Agent”指的是逻辑单元的单一性，不是网络调用的单一性。所有外部I/O必须前置（查DB、调API）或后置（发通知、写DB），LLM调用只负责纯粹的“思考”——基于已提供的上下文，做出结构化决策。我们现在的标准是：LLM调用必须在1.5秒内完成，超时即降级。

坑三：忽视Prompt版本管理，导致线上事故
有一次，算法同学在本地调试时，修改了Prompt中的一个枚举值（把'high'改成'urgent'），测试通过后直接推送到生产环境，但后端代码里的Pydantic模型没同步更新，导致所有'urgent'值被模型拒绝，整个服务瘫痪。教训：Prompt必须像代码一样管理！我们后来强制要求：所有Prompt变更，必须提交PR，PR中必须包含：a) 修改的Prompt diff；b) 对应的Pydantic模型变更；c) 全量回归测试报告。CI流水线会自动执行这三项检查，任一失败则阻断合并。现在，Prompt和代码的版本永远强一致。

4.3 实战调试技巧：三分钟定位90%的问题

• 技巧一：“逆向日志追踪法”：当看到一个错误输出时，不要从头看日志，而是直接搜索_debug字段，找到llm_raw_output，把它复制出来，粘贴到你的本地调试环境，用同一个Prompt、同一个模型、同样的输入，重新跑一遍。90%的情况下，你能立刻复现问题，并看到是LLM的哪一步推理出了岔子。

• 技巧二：“规则剥离测试法”：怀疑是规则引擎干扰了LLM的正常发挥？在沙箱环境中，临时禁用所有规则引擎（设置RULE_ENGINE_ENABLED=false），只让LLM裸跑。如果问题消失，说明是规则逻辑与LLM逻辑产生了冲突；如果问题依旧，那问题一定在LLM侧或输入数据侧。

• 技巧三：“最小输入构造法”：当一个复杂case失败时，不要试图分析整个长文本。用“减法”原则，不断删减输入，直到找到最短的、仍能复现问题的输入片段。这个最小输入，往往直指Prompt中某个隐含假设的漏洞（比如，它假设用户一定会写“订单号”，但实际用户只写了“单号”）。

这些技巧，都是我在凌晨三点对着日志屏幕熬出来的。它们不写在任何官方文档里，但能帮你把90%的线上问题，从“大海捞针”变成“有的放矢”。

5. 工具链与工程实践：让单Agent落地生根

5.1 核心工具选型：为什么是这些，而不是那些？

单Agent的成功，极度依赖背后工具链的成熟度。我们不是为“炫技”选型，而是为“稳”和“快”选型。以下是经过一年线上验证的核心工具栈：

• LLM网关：LiteLLM
  为什么不用自研？因为它的核心价值是“统一API抽象”。我们同时对接GPT-4、Claude-3、Gemini、以及本地Phi-3，LiteLLM用同一套completion()接口屏蔽了所有模型的差异（如message格式、streaming开关、token计数方式）。更重要的是，它内置了重试、熔断、超时、日志、监控埋点，我们省去了80%的胶水代码。它不解决LLM能力问题，但完美解决了LLM工程化问题。

• 规则引擎：Durable Rules
  为什么不用Drools或Easy Rules？因为我们需要极致的轻量和嵌入性。Durable Rules是一个纯Python库，规则定义就是Python函数，没有XML、没有DSL，学习成本为零。它支持复杂的事件模式匹配（如“当A发生，且B在5分钟内未发生，则触发C”），正好满足我们对“事件驱动型规则”的需求。它的最大优势是：规则代码和业务代码完全融合，调试时F5一键跟进，没有上下文切换。

• 可观测性：OpenTelemetry + ELK
  为什么不用Datadog或New Relic？因为我们要的是“穿透式”而非“概览式”。OpenTelemetry的Trace SDK可以让我们在Prompt渲染、LLM调用、规则匹配、JSON解析等每一个关键节点，手动打点，生成完整的Span链。这些Span数据导出到ELK后，我们可以用KQL精准查询“所有llm_duration_ms > 2000且rule_hit_count = 0的trace”，瞬间定位到是LLM性能问题，而非规则问题。商业APM工具的默认仪表盘，永远无法满足这种深度下钻需求。

• 部署与CI/CD：Docker + GitHub Actions
  单Agent的镜像非常小（<200MB），因为它只打包了Python依赖、Prompt模板、规则库YAML、和一个轻量级Web服务器（FastAPI）。GitHub Actions流水线严格遵循“测试先行”：每次PR，必须通过单元测试（Mock LLM）、集成测试（本地LiteLLM）、端到端测试（真实LLM调用）。只有全量测试通过，才能合并。这保证了每次上线的Agent，都是经过千锤百炼的。

提示：工具选型的黄金法则是“够用就好，能少则少”。我们曾评估过LangChain，但它庞大的抽象层和复杂的概念（Chain、Tool、AgentExecutor）与我们追求的“简洁、可控、可预测”背道而驰。最后，我们只用了LangChain的PromptTemplate类来渲染Prompt，其他一概不用。单Agent的哲学，就是把复杂性扼杀在摇篮里。

5.2 团队协作模式：打破“算法-工程-产品”的墙

单Agent架构的成功，不仅是技术选择，更是组织协作模式的变革。我们废除了传统的“算法提PR，工程接需求，产品做验收”的瀑布流，代之以“三合一”Feature Team：

• 成员：1名AI工程师（懂Prompt、懂LLM API）、1名后端工程师（懂规则引擎、懂可观测性）、1名AI产品经理（懂业务、懂数据、懂用户反馈）。

• 工作节奏：以“单个业务场景”为单位，进行双周迭代。例如，“优化信用卡账单争议处理”就是一个完整迭代。三人从第一天起就坐在一起，共同：

  • 分析100条真实争议case，找出TOP3失败模式；
  • 共同设计Prompt的五个模块，产品经理写业务逻辑，AI工程师写技术约束，后端工程师写规则伪代码；
  • 共同编写测试用例（正例、负例、边界例）；
  • 共同在沙箱环境中调试，产品经理直接操作，工程师实时解释日志。

• 交付物：不是“一个模型”或“一个API”，而是一个“可验证的业务结果”——例如，“将账单争议的自动分类准确率从78%提升到92%，且P95响应时间<0.5秒”。这个结果，由三方共同签字确认。

这种模式下，没有“算法说这个case太难，做不了”，也没有“工程说这个需求要排期三个月”，更没有“产品说这个效果我看不懂”。所有人对同一个目标负责，对同一份日志负责，对同一个用户的体验负责。它让单Agent从一个技术方案，变成了一个团队共识。

5.3 成本与ROI：一笔算得清的经济账

最后，也是最关键的，是成本。很多人觉得“单Agent省资源”，但具体省多少？我们做了详细测算（基于日均100万次调用）：

这张表说明，单Agent的“甜蜜点”，不仅是