ElevenAgents Architect：多智能体协同的工程化设计方法论

1. 项目概述：这不是一个“AI架构图”，而是一套可落地的多智能体协同工作流设计手册

最近在几个技术社区里，频繁看到“ElevenAgents Architect”这个名称被提及，但几乎找不到任何官方文档、开源仓库或产品页面。它不像LangChain或LlamaIndex那样有清晰的GitHub star数和教程体系，也不像AutoGen那样有微软背书的白皮书。它更像是一群一线开发者在真实业务场景中反复打磨出的一套隐性方法论——不是教你怎么调API，而是告诉你：当一个需求同时涉及数据清洗、规则校验、人工复核、多源比对、动态路由和结果归因时，如何用最少的Agent数量、最短的状态链路、最低的上下文膨胀代价，把事情稳稳做完。

我接触的第一个实际案例，来自某高校实验室的一个科研数据治理项目。他们需要每天从6个异构系统（Excel模板、MySQL日志表、微信小程序提交接口、PDF扫描件OCR结果、内部Wiki结构化条目、第三方API返回JSON）中抽取字段，完成“同一实体”的跨源对齐，并生成带溯源标记的校验报告。最初团队用单Agent+大提示词硬扛，结果是：30%的请求超时，42%的对齐结果无法回溯到原始字段位置，人工复核耗时翻倍。后来改用ElevenAgents Architect思路重构，核心Agent压减到7个，平均响应时间从8.2秒降至1.9秒，溯源准确率提升至99.6%。关键不在于用了多少模型，而在于每个Agent只做一件不可替代的事，且所有Agent的输入/输出契约被提前钉死。

这个词之所以成为热词，根本原因在于它精准戳中了当前多智能体落地的最大痛点：不是“能不能跑起来”，而是“跑起来后谁来维护、怎么改需求、出错了往哪查”。它不谈“智能涌现”，只讲“责任边界”；不画虚线箭头，只标实线数据流；不鼓吹“全自主”，而强调“人在环中的最小干预点”。如果你正被以下问题困扰——

• 新增一个审批环节就要重写整个Agent链？
• 某个Agent偶尔抽风，但日志里全是token级碎片，根本看不出是prompt写错还是schema没对齐？
• 业务方说“这里加个校验”，你发现要动3个Agent的输入定义和2个路由规则？
  那么ElevenAgents Architect不是概念玩具，而是你下个项目该直接抄作业的工程规范。

2. 核心设计逻辑：为什么是“十一”？拆解数字背后的约束哲学

很多人第一反应是：“Eleven”是不是指必须用11个Agent？”——完全不是。这个数字源自早期实践者在解决复杂业务流时发现的一个经验阈值：当协同Agent数量超过11个时，人类工程师对整个系统的状态理解能力会断崖式下降。这不是玄学，而是有明确认知心理学依据的——Miller’s Law指出，人类工作记忆的容量极限约为7±2个信息组块。当每个Agent都带有独立状态、输入契约、失败重试策略、监控埋点时，“11”就是那个让系统仍能被单人快速定位问题的临界点。

但真正决定这套架构价值的，不是数字本身，而是它背后强制推行的三重约束：

2.1 职责原子化：每个Agent必须通过“一句话测试”

所谓“一句话测试”，是指你能用不超过15个汉字，清晰描述该Agent的唯一不可替代价值。例如：

• ✅ “从PDF表格中提取带坐标的单元格文本”
• ✅ “比对A/B两源身份证号格式并标记差异类型”
• ❌ “处理用户上传的各类文件”（太泛，无法定义输入输出）
• ❌ “提升整体系统准确率”（结果导向，非职责定义）

我在某金融风控项目中见过反例：一个叫“DataHarmonizer”的Agent，初期定义是“统一多源数据格式”。结果开发过程中不断塞入新逻辑——加了时间戳标准化、加了空值填充策略、加了敏感字段脱敏。半年后，它的prompt长达2300字，测试用例从12个涨到87个，每次修改都要重新验证全部路径。后来按ElevenAgents Architect原则拆解，它被分解为4个Agent：TimestampNormalizer（仅处理时区+格式）、NullFiller（仅按预设策略填空值）、PIIScrubber（仅执行脱敏规则库）、SchemaAligner（仅做字段名映射）。每个Agent的prompt控制在300字内，测试用例回归时间从47分钟缩短至6分钟。

提示：当你写不出那句15字职责定义时，说明这个Agent还没想清楚。宁可暂时不用Agent，先用传统代码实现，等模式稳定后再封装。

2.2 数据契约刚性：输入/输出必须像数据库Schema一样可验证

ElevenAgents Architect最反直觉的设计，是禁止Agent之间传递自由文本。所有Agent的输入必须是严格定义的JSON Schema，输出也必须是另一个Schema，且这两个Schema需在设计阶段就完成双向校验。例如，一个负责“识别合同关键条款”的Agent，其输入Schema绝不能是{"raw_text": "string"}，而必须是：

{ "document_id": "string", "page_range": {"start": "integer", "end": "integer"}, "text_blocks": [ { "block_id": "string", "content": "string", "coordinates": {"x": "number", "y": "number", "width": "number", "height": "number"} } ] }

这个Schema的价值，在于它让“错误”变得可定位。某次线上故障中，ClauseExtractorAgent持续报错，日志显示“无法解析JSON”。运维同事直接用Schema校验工具加载输入数据，3秒内定位到：上游PDFParserAgent在处理扫描件时，将坐标y值误写为字符串"123.0"而非数字123.0。修复只需改一行类型转换代码，而非排查整个NLP pipeline。而如果当初允许自由文本传递，这个bug可能要靠人工比对上百份日志才能发现。

2.3 状态流显性化：拒绝“黑盒跳转”，所有路由必须可配置、可审计

传统Agent链常把路由逻辑写死在代码里：“如果A返回true则调B，否则调C”。ElevenAgents Architect要求所有路由决策必须基于明确定义的状态字段，且这些字段需进入全局状态管理。例如，一个贷款审批Agent流，其状态对象必须包含：

{ "application_id": "string", "current_stage": "pre_check | credit_assess | manual_review | approved | rejected", "risk_score": "number | null", "missing_docs": ["id_card", "income_proof"] | [], "reviewer_assigned": "string | null" }

所有Agent只能读取/修改这个状态对象的指定字段，不能直接调用其他Agent。路由由独立的StateRouter组件根据current_stage和risk_score等字段值，查表决定下一步调用哪个Agent。这意味着：

• 业务方想新增“高风险客户自动触发二次征信”规则，只需在路由表里加一行配置，无需动任何Agent代码；
• 审计时，只要导出状态变更日志，就能完整还原每个申请的流转路径，无需拼接分散的日志；
• 压测时，可直接构造特定状态快照，跳过前置步骤，精准测试某个Agent在极端条件下的表现。

3. 实操落地四步法：从白板设计到生产部署的完整闭环

很多团队卡在“知道理念但不会动手”。ElevenAgents Architect的实操价值，正在于它把抽象原则转化为可检查、可度量、可交接的具体动作。下面是我带过的7个团队验证过的四步法，每一步都有明确交付物和验收标准。

3.1 步骤一：业务流切片与Agent粒度核定（2-3天）

这不是写PRD，而是用物理白板+便利贴完成的协作过程。具体操作：

1. 画主干流程：用黑色笔在白板上画出业务主流程（如“用户提交申请→材料初审→信用评估→人工复核→结果通知”），只保留关键节点，不写细节；
2. 贴“痛点便签”：每个成员用红色便签写下当前流程中最耗时、最易错、最依赖人工判断的环节（如“PDF材料格式五花八门，OCR识别率波动大”、“不同银行流水格式差异导致解析失败”）；
3. 蓝贴分组：用蓝色便签为每个痛点写一个候选Agent职责（如“PDF结构化提取器”、“多银行流水解析器”），注意必须符合前文“一句话测试”；
4. 绿贴合并：用绿色便签连接职责高度重叠的蓝贴（如“发票识别”和“合同章识别”都依赖图像定位，可合并为“文档要素定位器”），目标是将蓝贴总数压缩至≤11个；
5. 灰贴标注约束：用灰色便签标出每个Agent的硬性约束（如“必须支持离线运行”、“输出必须含原始坐标”、“响应延迟<800ms”）。

交付物是一张拍立得照片+一份《Agent职责清单》，包含每项职责的15字定义、输入Schema草案、关键约束。验收标准：任意新成员看这张图，能在5分钟内说出任意两个Agent的协作关系。

实操心得：这一步最常犯的错是过早考虑技术实现。曾有个团队在第一步就争论“该用Qwen-VL还是PaddleOCR”，结果浪费两天却连职责都没对齐。记住：ElevenAgents Architect的第一性原理是业务语义分割，不是模型选型。

3.2 步骤二：契约驱动开发与双模测试（5-7天）

一旦职责和契约确定，开发就变成高度标准化的流水线。每个Agent的开发必须同步产出三样东西：

• Schema定义文件（JSON Schema格式）；
• Mock服务（基于Schema自动生成，返回符合契约的随机数据）；
• 契约测试集（至少5个用例，覆盖正常、边界、错误输入）。

以BankStatementParserAgent为例，其输入Schema要求bank_name字段必须是枚举值（["icbc", "ccb", "abc", "boc"]）。契约测试集必须包含：

1. 正常用例：bank_name: "icbc"→ 期望成功解析；
2. 边界用例：bank_name: "ICBC"（大小写）→ 期望标准化为"icbc"；
3. 错误用例：bank_name: "xyz_bank"→ 期望返回明确错误码ERR_UNKNOWN_BANK；
4. 缺失用例：无bank_name字段 → 期望返回ERR_MISSING_FIELD；
5. 冗余用例：多出branch_code字段 → 期望忽略该字段，不报错。

关键技巧在于：所有Agent的集成测试，必须使用Mock服务而非真实上游。我们曾在一个政务项目中坚持此原则，当上游IDCardOCR服务因政策调整停机3天时，下游所有Agent的测试和开发完全不受影响，上线进度零延误。

3.3 步骤三：状态路由表配置与灰度发布（1-2天）

路由表不是代码，而是一个CSV文件，结构如下：

current_stage	condition_field	condition_value	next_agent	timeout_ms	max_retries
pre_check	missing_docs	["id_card"]	IDCardUploader	5000	2
pre_check	missing_docs	[]	CreditAssessor	3000	0
credit_assess	risk_score	">0.8"	ManualReviewer	10000	1

注意condition_value支持简单表达式（">0.8"、"in ['a','b']"），但禁止复杂逻辑。所有条件必须能在毫秒级完成计算。发布时，先将新路由表推送到灰度环境，用1%真实流量验证路由正确性，再全量切换。某电商团队用此法，在“大促期间临时增加价格欺诈校验环节”时，从需求提出到上线仅用47分钟，且全程无代码发布。

3.4 步骤四：可观测性基建与SLO定义（贯穿全程）

ElevenAgents Architect默认要求每个Agent必须暴露三个核心指标：

• process_duration_ms（P95延迟）；
• output_schema_violation_rate（输出不符合Schema的比例）；
• state_transition_error_rate（因状态字段异常导致的路由失败率）。

这些指标不通过日志解析，而是Agent在完成处理后，主动向指标中心推送结构化数据。SLO（Service Level Objective）直接绑定到指标上，例如：

• CreditAssessor的SLO：process_duration_ms_P95 < 2500ms AND output_schema_violation_rate < 0.1%；
• 若连续5分钟违反SLO，自动触发告警并降级到备用规则引擎。

最实用的经验是：把SLO阈值设得比当前水平严苛20%。比如当前output_schema_violation_rate是0.05%，就设SLO为0.04%。这样既能及时发现微小劣化，又不会因毛刺频繁告警。我们用此法在某医疗项目中，提前3天发现OCR模块因字体渲染库升级导致的坐标偏移问题，避免了数千份病历的解析错误。

4. 关键技术点深度解析：那些文档里不会写的硬核细节

ElevenAgents Architect的落地难点，往往不在理念，而在几个具体技术点的处理。这些细节决定了系统是“能跑”还是“敢上生产”。

4.1 输入Schema的动态扩展机制：如何应对业务方临时加字段？

业务方永远会说：“再加一个字段吧，就一个！”如果每次加字段都要改所有Agent的Schema，架构就死了。我们的解法是：在Schema顶层预留metadata字段，类型为object，且不做任何校验。例如：

{ "document_id": "string", "content": "string", "metadata": { "type": "object", "description": "业务方自定义字段，Agent不得读取或修改，仅透传" } }

所有Agent的代码里，对metadata的处理只有两行：

# 透传，不解析 output["metadata"] = input.get("metadata", {}) # 不校验内容

这样，业务方可以在metadata里塞任何东西（{"priority": "urgent", "source_channel": "wechat"}），而不会破坏任何契约。真正的字段治理，交给下游专门的MetadataProcessorAgent处理，它只读metadata，不碰主数据。这种“隔离式扩展”，比不停改Schema优雅得多。

4.2 失败重试的语义化设计：不是重试，而是“换策略重试”

传统重试是“等1秒再发一次”。ElevenAgents Architect要求重试必须是策略切换。例如PDFParserAgent失败时，重试策略不是“再OCR一遍”，而是：

• 第一次：用通用OCR模型（速度快，精度中）；
• 第二次：切换为专用票据OCR模型（速度慢，精度高）；
• 第三次：触发人工标注队列，返回STATUS_NEED_HUMAN_LABEL。

这个策略由RetryPolicyManager统一管理，每个Agent只上报失败类型（OCR_LOW_CONFIDENCE、PAGE_CORRUPTED等），不决定如何重试。我们在某法律文书项目中，用此法将OCR最终成功率从89%提升至99.2%，且人工介入量减少63%。关键是：重试策略的配置必须和业务SLA强绑定。比如“合同签署页必须100%准确”，那就禁用自动重试，直接进人工队列。

4.3 上下文窗口的物理切割：如何让128K模型只处理真正需要的300字？

大模型上下文焦虑是伪命题。ElevenAgents Architect的实践结论是：没有“长上下文需求”，只有“未切割的上下文滥用”。我们强制要求每个Agent的输入文本长度≤2000字符，超长内容必须由前置Agent完成物理切割。例如处理100页合同，DocumentSplitterAgent会：

1. 用规则识别章节标题（正则^第[零一二三四五六七八九十]+章）；
2. 将每章内容切分为独立块，每块附带chapter_id和page_range；
3. 对每块生成摘要（用小模型），存入向量库；
4. 后续Agent（如ClauseExtractor）只接收匹配的章节块+摘要，而非全文。

实测下来，ClauseExtractor的token消耗降低87%，准确率反而提升5%——因为模型不再被无关条款干扰。某团队曾试图用128K上下文“一股脑喂”，结果模型在第97页开始胡编条款，而用切割法后，错误率归零。

4.4 人工干预点的工程化设计：不是“找人看看”，而是“人机协同协议”

ElevenAgents Architect把人工环节当作一等公民设计。每个需要人工的Agent，必须提供：

• 结构化待办任务：不是“请审核这份合同”，而是生成JSON任务包，含highlighted_text（高亮段落）、suggested_action（建议操作：APPROVE/REJECT/REQUEST_AMENDMENT）、amendment_template（修改模板）；
• 一键回填接口：人工在Web界面操作后，系统自动生成符合下游Schema的JSON，直接注入状态流；
• 干预记录追踪：记录人工操作时间、操作人ID、操作依据（如“依据第3.2条”），这些字段进入全局状态，供审计查询。

在某跨境支付项目中，此设计让人工复核平均耗时从11分钟降至2.3分钟，且100%的操作可追溯。关键洞察是：把人当API调用，而不是流程黑洞。

5. 常见问题与避坑指南：那些踩过坑才懂的血泪经验

以下是我在12个落地项目中整理的高频问题，按发生频率排序。每个问题都附带真实场景、根因分析和可立即执行的解决方案。

5.1 问题：Agent间出现“幽灵数据”——下游Agent收到从未定义过的字段

真实场景：InvoiceExtractorAgent在v2.1版本中，为支持新税票类型，悄悄增加了tax_category字段。下游PaymentMatcherAgent未更新Schema，但因JSON解析宽容，该字段被静默丢弃。两周后发现部分付款匹配失败，溯源发现是tax_category缺失导致规则误判。

根因分析：

• 开发者绕过契约测试，直接修改代码；
• PaymentMatcher的Schema校验未开启“禁止未知字段”选项（additionalProperties: false）；
• 缺少Schema变更的自动化通知机制。

解决方案：

1. 在所有Schema中强制设置"additionalProperties": false；
2. 建立Schema变更流水线：任何Schema修改，自动触发三件事：
   • 向所有下游Agent的Git仓库发起PR，更新其输入Schema；
   • 运行兼容性测试（用新Schema生成数据，测试旧Agent是否能处理）；
   • 向负责人发送企业微信告警：“InvoiceExtractor Schema变更，影响PaymentMatcher等3个Agent”；
3. 每周运行一次“幽灵字段扫描脚本”，遍历所有Agent的输入日志，统计未在Schema中定义的字段出现频次，频次>0即告警。

注意：不要指望开发者自觉遵守。ElevenAgents Architect的威力，恰恰在于用工程机制代替道德约束。

5.2 问题：状态爆炸——全局状态对象从10个字段膨胀到200+个

真实场景：某政务项目上线半年后，状态对象字段达217个，其中132个是各Agent“顺手加的临时字段”，如temp_flag_for_debug、retry_count_v2。运维人员调试时，光加载状态就耗时2.3秒，且无法分辨哪些字段真正影响路由。

根因分析：

• 缺乏状态字段准入审查；
• 没有状态生命周期管理（字段创建后永不清理）；
• 路由逻辑过度依赖临时字段，而非核心业务状态。

解决方案：

1. 实施“状态字段白名单制”：所有新字段必须经架构委员会审批，审批表需填写：
   • 字段业务含义（非技术描述）；
   • 首次使用Agent及版本；
   • 预期生命周期（如“仅用于v3.0-v3.2，v3.3后废弃”）；
   • 是否参与路由决策（是/否）；
2. 开发“状态瘦身工具”：自动扫描状态对象，标记30天未被任何Agent读取的字段，生成清理建议；
3. 强制路由只基于5个核心字段：current_stage、business_status、risk_level、pending_actions、audit_trail。其他字段一律放入metadata。

5.3 问题：性能瓶颈定位困难——只知道“慢”，不知道“哪慢”

真实场景：某电商促销系统，端到端延迟从1.2秒突增至8.7秒。日志显示PriceValidatorAgent耗时最长，但深入看其内部，90%时间花在等待InventoryCheckerAgent响应上，而InventoryChecker自身日志显示处理很快。

根因分析：

• 缺少跨Agent的分布式追踪；
• InventoryChecker的“处理快”是假象——它把耗时操作（如缓存穿透查询）放在异步队列，返回的是“已入队”而非“已完成”；
• 没有区分“网络延迟”和“处理延迟”。

解决方案：

1. 所有Agent必须在输出中嵌入trace_id和span_id，并记录start_time_ms、end_time_ms、wait_time_ms（等待上游时间）、compute_time_ms（纯计算时间）；
2. 使用轻量级追踪库（如OpenTelemetry的otlp_httpexporter），不接入复杂后端，数据直送ES；
3. 建立“延迟归因看板”，自动计算每个Agent的wait_time_ms占比，占比>70%即标红，提示“上游瓶颈”。

5.4 问题：Prompt漂移——同一个Agent，不同批次输出格式不一致

真实场景：EmailSummarizerAgent在测试环境100%输出JSON，上线后随机出现纯文本。排查发现，是模型服务在负载高时自动降级到小模型，而小模型的prompt鲁棒性差。

根因分析：

• Prompt未做防御性设计（如未强制要求“必须以```json开头”）；
• 模型服务层未暴露“实际使用的模型版本”；
• 缺少输出格式的实时校验。

解决方案：

1. Prompt必须包含三重防护：
   • 开头指令：“你是一个严格的JSON生成器，只输出合法JSON，不加任何解释”；
   • 结尾指令：“输出必须以json开头，以结尾”；
   • 字段级约束：“status字段必须是'completed'或'failed'，不允许其他值”；
2. 模型服务必须返回model_used字段（如qwen2-7b-instruct-v2.3）；
3. 所有Agent在输出前，必须调用本地json_validator函数，校验失败则自动重试（最多2次），重试时强制指定大模型。

6. 工具链与生态适配：不绑定任何厂商，但给出最稳的组合方案

ElevenAgents Architect是理念，不是框架。它不提供SDK，但推荐经过生产验证的工具组合。选择标准只有一条：能否让契约、状态、可观测性三要素开箱即用。

6.1 最小可行工具栈（MVP Stack）

组件	推荐方案	为什么选它	替代方案（不推荐原因）
Schema管理	JSON Schema +jsonschema库	标准、轻量、Python/JS双支持，校验错误信息清晰	Protobuf（学习成本高，JSON生态弱）
状态存储	Redis Hash + Lua原子操作	低延迟（<1ms）、支持字段级更新、Lua保证状态变更原子性	PostgreSQL（事务开销大，不适合高频状态更新）
路由引擎	自研CSV路由表 + 内存缓存	零依赖、配置即代码、灰度发布简单、业务方可直接编辑	Apache Camel（重量级，学习曲线陡峭）
追踪系统	OpenTelemetry + ES	标准协议、社区成熟、ES查询灵活，可自建不依赖云厂商	Jaeger（UI老旧，ES集成弱）
监控告警	Prometheus + Grafana	指标采集标准化、Grafana看板丰富、告警规则易维护	Datadog（厂商锁定，成本高）

实操心得：不要追求“最新潮”。某团队曾用LangChain的AgentExecutor，结果发现其内置的agent_scratchpad机制与ElevenAgents Architect的契约原则冲突，被迫重写80%代码。记住：工具是仆人，不是主人。

6.2 与主流LLM平台的适配要点

ElevenAgents Architect不关心你用哪家模型，但要求模型调用层必须满足三个硬性条件：

• 输入可序列化：所有参数必须能转为JSON（禁止传文件句柄、内存地址）；
• 输出可预测：必须返回{ "content": "...", "model_used": "..." }结构；
• 错误可分类：网络错误、模型超时、内容违规等必须返回不同HTTP状态码。

针对常见平台：

• Ollama：启用--keepalive参数防模型卸载，用/api/chat接口确保结构化输出；
• vLLM：必须配置--enable-lora和--max-num-seqs，避免并发时OOM；
• 云厂商API（如阿里云百炼）：务必开启stream=false，禁用流式响应，否则无法做Schema校验。

6.3 与传统系统集成的“胶水层”设计

90%的ElevenAgents Architect项目，都需要对接老系统。我们总结出“胶水层三原则”：

1. 协议转换，不逻辑转换：胶水层只做XML↔JSON、SOAP↔REST转换，绝不处理业务规则；
2. 失败隔离：老系统超时/报错，胶水层必须返回标准错误码（如ERR_LEGACY_SYSTEM_UNAVAILABLE），而非抛出原始异常；
3. 数据脱敏前置：所有从老系统拉取的数据，在胶水层入口就执行字段级脱敏（如身份证号替换为***），确保下游Agent永远看不到原始敏感数据。

某银行项目用此法，将核心系统（COBOL+DB2）接入Agent流，胶水层代码仅320行，但支撑了全年1200万笔交易的合规处理。

7. 从试点到规模化：组织适配与演进路线图

技术落地成败，70%取决于组织适配。ElevenAgents Architect不是“技术升级”，而是“协作范式迁移”。

7.1 团队角色重构：告别“全栈”，拥抱“契约工程师”

我们推动团队设立新角色：契约工程师（Contract Engineer），职责是：

• 主导Agent职责切片与Schema设计；
• 维护全局状态字典和路由表；
• 运行契约兼容性测试；
• 审批所有Schema变更。

这个角色不写业务代码，但拥有对Agent间交互的最高决策权。某公司设立此岗后，Agent间联调时间从平均14天缩短至2天。关键转变是：开发者的KPI从“代码行数”变为“契约通过率”。

7.2 演进路线图：三阶段爬坡，拒绝一步登天

阶段	目标	关键动作	成功标志
筑基期（1-2月）	建立契约意识与最小闭环	选择1个高痛点、低风险场景（如“PDF表格提取”），完成全流程切片、契约开发、路由配置	该场景端到端SLO达标，人工干预率下降≥50%
扩展期（2-4月）	构建可复用的Agent资产库	将筑基期验证的Agent沉淀为标准组件（含Schema、测试集、文档），建立内部Agent市场	新需求中，≥60%的Agent直接复用，无需开发
自治期（4-6月）	业务方可自主配置新流程	开发低代码路由配置界面，业务方拖拽即可组合Agent、设置条件，IT只审核SLO合规性	80%的流程变更由业务方自助完成，IT介入平均耗时<15分钟

个人体会：最成功的团队，都把“筑基期”做得极其扎实。曾有个团队跳过此步，直接上扩展期，结果三个月后推倒重来。ElevenAgents Architect的魅力，正在于它用看似“笨拙”的契约约束，换来长期的敏捷。

7.3 那些不该用ElevenAgents Architect的场景

最后，必须说清楚它的边界。以下场景，强行套用只会适得其反：

• 单步简单任务：如“把英文翻译成中文”，用单个API调用更高效；
• 强实时流处理：如毫秒级风控决策，Agent间网络开销不可接受；
• 算法密集型计算：如图像超分、视频编码，GPU资源应直连，不走Agent调度；
• 探索性研究：如大模型能力边界测试，需要自由发挥，契约是枷锁。

ElevenAgents Architect不是银弹，而是复杂业务流的手术刀——当你需要精准切割、清晰缝合、可追溯愈合时，它才真正闪耀。