A Pei1. 复杂业务逻辑的架构选择困境
在构建基于大语言模型（LLM）的业务系统时，工程师们经常面临一个关键决策点：是将所有业务逻辑塞进一个"超级提示词"（Super Prompt），还是拆分成多个专业Agent进行协作？这个问题看似简单，实则涉及到LLM底层工作机制、系统工程方法论和实际维护成本的复杂权衡。
我经历过多个企业级AI项目的完整生命周期，发现大多数团队最初都会倾向于使用单一Prompt方案——因为它简单直接，不需要考虑模块间通信。但随着业务逻辑复杂度的提升，这种方案很快就会遇到瓶颈。上周刚接手的一个客户案例就很典型：他们的客服系统Prompt从最初的3条指令膨胀到27条约束条件后，响应质量开始断崖式下跌，出现了严重的指令遗漏和逻辑混乱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 关键判定指标解析
2.1 指令熵值的量化评估
指令熵（Instruction Entropy）是我在实践中总结的核心评估指标。它衡量的是单个Prompt中不同指令间的相互干扰程度。当你在一个Prompt中同时要求：
- 输出必须简短
- 要包含所有技术细节
- 使用非技术语言解释
- 给出3个具体案例
- 每个案例不超过2句话
模型就会陷入"指令过载"状态。根据我的实测数据，当约束条件超过10条时，GPT-4对每条指令的遵循准确率会从95%骤降到62%。这就像让一个人同时记住10个不同的任务要求，出错概率必然指数级上升。
重要提示：判断熵值过高的一个明显信号是，你开始需要在Prompt里写"尽管前面要求了A，但这里要优先考虑B"这类补偿性指令。
2.2 可维护性的工程考量
另一个关键指标是可维护性。最近我们重构了一个金融合规检查系统，原版使用2800词的Super Prompt，每次业务规则变更都需要：
- 在庞杂的文本中找到对应段落
- 修改后担心影响其他关联规则
- 进行完整的端到端测试
拆分成KYC Agent、风控Agent和报告Agent后，每个模块的Prompt不超过500词。现在修改KYC规则时，我们只需要：
- 调整KYC Agent的Prompt
- 运行该Agent的单元测试
- 验证与其他Agent的接口协议
平均迭代周期从3天缩短到2小时。这种模块化架构特别适合需要频繁调整的业务场景。
3. 拆分决策的临界点判断
3.1 明确的任务拆分信号
根据20+个项目的实施经验，我总结出必须进行拆分的三个黄金标准：
-
条件分支超过3层
当业务逻辑出现"如果A则B，否则如果C则D，再否则E"的结构时，就应该考虑状态机驱动的多Agent方案。例如电商退货流程：mermaid复制graph TD A[退货申请] --> B{金额>1000?} B -->|是| C[高级审核] B -->|否| D{商品完好?} D -->|是| E[自动退款] D -->|否| F[人工审核] -
工具调用组合复杂
需要交替使用不同工具的场景，比如：- 先调用数据库查询
- 再用计算结果调用API
- 最后用API结果生成图表
这类操作应该分配给专门的查询Agent、计算Agent和可视化Agent。
-
存在后置校验需求
当需要对中间结果进行严格验证时（如法律条款审核、财务数据复核），拆分成独立Agent可以在流程中插入校验节点。我们有个合同管理系统就采用"生成→审计→修正"的三Agent流水线，错误率比单Prompt方案降低了78%。
3.2 保留单Prompt的场景
简单线性任务仍然适合单Prompt方案，例如：
- 单轮问答
- 基础文本转换
- 无需上下文的独立任务
最近优化的一个邮件自动回复系统，保持单Prompt结构反而更高效，因为：
- 任务类型单一（客户咨询→标准回复）
- 无需工具调用
- 没有条件分支
- Prompt约束仅5条
4. 多Agent系统的实现模式
4.1 分层协作架构
在实践中我主要采用三种协作模式：
星型拓扑
中央路由Agent负责任务分发和结果聚合，适合有明确主从关系的场景。例如客户服务系统：
code复制 [路由Agent]
/ | \
[技术支持] [账单查询] [售后处理]
流水线拓扑
数据按固定顺序流经各个Agent，适合分阶段处理的场景。我们的保险理赔系统就采用：
code复制[材料接收] → [信息提取] → [合规检查] → [理算] → [生成报告]
自治协作
Agent之间直接通信，适合需要灵活交互的场景。使用这种模式构建的智能投资顾问：
code复制[市场分析] ↔ [风险评估] ↔ [组合优化]
4.2 状态机控制实践
对于复杂业务流程，我推荐使用LangGraph等工具实现状态机控制。上周刚完成的一个供应链案例中，我们这样设计：
python复制from langgraph.graph import Graph
workflow = Graph()
# 定义节点
workflow.add_node("order_validation", validate_order)
workflow.add_node("inventory_check", check_inventory)
workflow.add_node("payment_processing", process_payment)
# 定义边
workflow.add_edge("order_validation", "inventory_check")
workflow.add_conditional_edges(
"inventory_check",
lambda x: "enough_stock" if x["in_stock"] else "backorder",
{"enough_stock": "payment_processing", "backorder": "order_validation"}
)
这种显式定义的流程具有三大优势：
- 每个节点的输入输出明确
- 可以插入任意校验点
- 调试时可以单步执行
5. 避坑指南与性能优化
5.1 常见陷阱警示
过度拆分反模式
曾见过一个团队把每个简单功能都拆成独立Agent，导致：
- 通信开销占总耗时40%
- 调试需要启动全部组件
- 认知复杂度反而上升
经验法则是：单个Agent的Prompt应该能在1屏内完整显示（约1500词），且功能描述能用1句话说清。
状态污染问题
在多轮交互中，Agent可能携带错误状态。解决方案：
- 关键节点重置对话历史
- 使用独立的记忆管理Agent
- 采用显式状态传递（如JSON blob）
5.2 性能调优技巧
通信优化
Agent间传输大文本会显著拖慢速度。我们的最佳实践：
- 只传递必要的结构化数据
- 对大型附件使用共享存储引用
- 设置消息TTL避免堆积
并发控制
并行调用多个Agent时要注意：
- 设置全局超时（如5秒）
- 实现断路器模式
- 对关键路径做串行化处理
实测数据显示，合理的并发策略可以使吞吐量提升3-8倍。最近优化的一个电商推荐系统，通过以下配置将95线从12秒降到2.3秒：
yaml复制agent_parallelism:
product_search: 3
user_profile: 2
ranking: 1 # 关键路径串行
timeout_ms: 4500
circuit_breaker:
failure_threshold: 3
reset_timeout: 60000
6. 演进路线与未来展望
随着业务规模扩大，我们的多Agent系统经历了三个阶段：
-
脚本拼接阶段
用Python脚本硬编码调用逻辑python复制def process_order(): validation_result = validate(order) if validation_result.ok: inventory = check_inventory() # 手动传递状态... -
框架化阶段
采用LangChain等框架python复制
chain = ( validate_order | check_inventory | process_payment ) -
平台化阶段
构建可视化编排平台code复制[Web UI] → [工作流引擎] → [Agent集群]
当前正在探索的方向包括：
- 动态Agent生成（按需创建专用Agent）
- 自适应路由（根据负载自动调整拓扑）
- 分布式事务（跨Agent的ACID保证）
这个演进过程给我的核心启示是：架构选择没有银弹，必须根据实际业务量和团队能力做务实决策。对于大多数企业来说，从关键业务环节开始逐步Agent化，往往比一次性全盘改造更稳妥有效。