多智能体协同这几年从论文里的概念一路卷到了工程落地但真正动手搭过的人都知道最难的从来不是让单个AI跑起来而是让多个AI在同一个任务里各司其职、互不打架同时还要让人能插得进手、管得住事。我最近在做一个AI代理代为交互的协同系统架构核心场景是用户只跟一个入口代理打交道背后有一组各怀绝技的AI代理分工干活有的负责拆解任务有的负责查资料有的负责执行有的负责审核最后把结果汇总回给用户。这套东西听起来像是把几个API串起来那么简单实际做下来踩的坑能写满一个笔记本。下面我把整个架构的设计思路、关键取舍、实测中遇到的问题和解决办法完整梳理一遍适合正在做多智能体系统、AI代理编排、或者想把自己手头的AI工具串成流水线的朋友参考。1. 为什么代为交互这个定位决定了整套架构的走向1.1 用户只面对一个代理背后却是一整个团队先把这个系统的核心定位说清楚。代为交互这四个字是整个架构的地基。它的意思是用户不需要知道背后有几个AI、分别是什么模型、怎么调度的用户只跟一个入口代理说话入口代理负责理解意图、拆解任务、分派给合适的下游代理、收集结果、整合成一份用户能看懂的回复。这个定位直接决定了几个架构上的硬约束。第一入口代理必须足够薄它不能自己去做所有事否则就退化成了单代理系统多代理协同的意义就没了。第二下游代理之间必须有明确的职责边界不然会出现两个代理抢同一个子任务、或者互相等对方干活导致死锁。第三整个链路必须可观测因为一旦出问题用户看到的是入口代理的回复但根因可能藏在任何一个下游代理里。我一开始的设计是把入口代理做得比较聪明让它自己判断该调用哪些下游代理。实测下来发现这样不行因为入口代理的判断本身就是一个不确定的环节它可能漏调、可能重复调、可能调错顺序。后来改成入口代理只负责意图识别任务拆解具体的分派逻辑交给一个独立的调度层入口代理的输出是一份结构化的任务清单调度层按清单去匹配下游代理。这样职责就清晰了入口代理管要做什么调度层管谁来做、按什么顺序做。1.2 单代理和多代理的边界到底在哪里很多人会问既然单个大模型能力已经很强了为什么还要搞多代理我的实测结论是单代理在单一领域、短链路、低并发的场景下确实够用但一旦任务涉及多个专业领域、需要多轮迭代、或者对某个环节的准确性要求极高单代理就会露出短板。举个具体的例子。用户说帮我分析一下这份合同里的风险点并给出修改建议。单代理的做法是读合同、分析风险、给建议一气呵成。但问题是分析和给建议是两个不同的能力维度分析要求严谨、不漏项给建议要求可操作、符合业务实际。单代理往往会在分析阶段就带入自己的主观判断导致风险点识别不全或者在给建议时过于笼统。多代理的做法是一个代理专门做风险识别它的提示词里写死了只找风险不给建议宁可多报不可漏报另一个代理专门做建议生成它的输入是风险清单任务是针对每一条风险给出具体的修改方案还有一个审核代理负责检查建议是否真的对应了风险、有没有自相矛盾。这样每个代理的职责单一输出质量反而更稳定。这里有个反直觉的点多代理系统的总token消耗通常比单代理高2到5倍因为代理之间的通信、任务清单的传递、结果的汇总都要消耗token。所以如果你的场景用单代理能搞定就别上多代理纯属浪费。1.3 架构分层入口层、调度层、执行层、审核层基于上面的分析我把整个系统分成了四层。入口层负责跟用户交互做意图识别和任务拆解调度层负责任务分派、依赖管理、超时控制执行层是各个专业代理各自干各自的活审核层负责质量把关和结果整合。这四层不是简单的串行关系。入口层和调度层之间是任务清单的传递调度层和执行层之间是子任务上下文的传递执行层和审核层之间是结果元数据的传递。每一层的输出都是结构化的这样下一层才能可靠地解析。我试过让层与层之间用自然语言传递结果就是各种解析错误、格式不一致、信息丢失。后来全部改成JSON schema约束的结构化输出虽然写schema麻烦一点但稳定性提升了一个数量级。这个经验我觉得挺重要的多代理系统里代理之间的接口比代理本身的智能更重要。2. 代理之间的通信协议结构化消息是稳定性的命根子2.1 为什么自然语言通信在多代理系统里会翻车我最早做的版本代理之间就是互相发自然语言消息。入口代理把任务拆解成一段文字调度代理读这段文字去理解要干什么执行代理读调度代理的指令去干活。这个方案在demo阶段看起来很美好因为大模型确实能理解自然语言。但一上量就崩了。崩的方式有很多种。第一种是理解偏差入口代理说分析合同风险调度代理理解成了分析合同条款执行代理理解成了分析合同的法律风险三个代理对同一个任务的理解都不一样。第二种是格式漂移执行代理返回的结果有时候是列表有时候是段落有时候还带markdown表格审核代理解析起来各种报错。第三种是信息丢失自然语言传递过程中一些关键的元数据比如任务ID、优先级、截止时间很容易被忽略或改写。这些问题的根因是自然语言是给人类用的它的优势是灵活劣势是歧义。代理之间不需要灵活需要的是精确。所以后来我把所有代理间的通信全部改成了结构化消息。2.2 消息结构的设计任务ID、类型、载荷、依赖、超时我最终定下来的消息结构包含五个核心字段。task_id是全局唯一的任务标识用UUID生成保证不会冲突。task_type是任务类型枚举比如intent_parse、task_split、execute、review、aggregate调度层根据这个字段决定把任务发给哪个代理。payload是任务的具体内容用JSON对象承载不同task_type的payload结构不同。dependencies是一个数组列出这个任务依赖哪些前置任务的task_id调度层据此做拓扑排序。timeout是超时时间单位秒超过这个时间任务会被标记为失败并触发重试或降级。{ task_id: a1b2c3d4-e5f6-7890-abcd-ef1234567890, task_type: execute, payload: { agent_role: risk_analyzer, input: { document: ..., focus_areas: [liability, termination, payment] } }, dependencies: [task_001, task_002], timeout: 120 }这个结构看起来简单但每个字段都是踩坑踩出来的。task_id用UUID是因为早期用自增ID结果多实例部署时冲突了。dependencies用数组而不是单个ID是因为有些任务确实依赖多个前置任务。timeout是必须的因为大模型调用有时候会卡住没有超时控制的话整个链路就挂在那里了。2.3 代理注册与发现让调度层知道有哪些代理可用调度层要分派任务首先得知道有哪些代理可用、每个代理能处理什么类型的任务。我一开始是硬编码的调度层里写死了一个映射表。但后来代理越来越多每次加新代理都要改调度层的代码太麻烦了。于是改成了代理注册机制。每个代理启动时向一个注册中心我用的是Redis写入自己的信息代理ID、支持的task_type列表、当前负载、健康状态。调度层分派任务前先从注册中心拉取可用代理列表然后根据task_type匹配、根据负载做均衡。代理定期发送心跳更新自己的状态如果超过一定时间没心跳调度层就把它标记为不可用。这个机制的好处是加新代理只需要启动它并注册调度层自动就能发现。坏处是引入了Redis这个依赖而且注册信息的准确性依赖代理的心跳机制。我实测下来心跳间隔设成10秒、超时阈值设成30秒比较合适太短了网络抖动会误判太长了故障发现不及时。2.4 消息队列还是直接调用两种通信模式的取舍代理之间的通信我试过两种模式。一种是直接调用调度层通过HTTP或gRPC直接调用执行代理的接口。另一种是通过消息队列调度层把任务丢进队列执行代理从队列里消费。直接调用的优点是简单、延迟低、容易调试。缺点是耦合度高执行代理挂了调度层就卡住了而且不好做负载均衡。消息队列的优点是解耦、天然支持异步和重试、容易扩展。缺点是引入了额外的组件调试起来麻烦而且消息的顺序性需要额外保证。我最终的方案是混合模式同步任务用直接调用异步任务用消息队列。所谓同步任务就是那些需要立即返回结果、用户等着看的任务比如意图识别。所谓异步任务就是那些耗时长、可以后台跑的任务比如大批量文档分析。这个划分不是绝对的可以根据实际场景调整。3. 任务拆解与分派从一句话到一张任务图3.1 入口代理怎么做意图识别和任务拆解入口代理的核心工作是把用户的一句话变成一张任务图。这个过程分两步先做意图识别判断用户到底想要什么再做任务拆解把大任务拆成可以分派给下游代理的子任务。意图识别我用的方法是分类槽位填充。分类是把用户输入归到一个预定义的意图类别里比如document_analysis、data_query、content_generation。槽位填充是提取意图相关的参数比如文档分析的槽位包括document_content、focus_areas、output_format。这两步可以用一个提示词搞定也可以用两个独立的调用我实测下来一个提示词搞定更稳定因为分类和槽位填充是强相关的。任务拆解我用的方法是模板动态调整。针对每个意图类别我预先定义了一个任务模板模板里写明了这个意图需要哪些子任务、子任务之间的依赖关系。比如document_analysis的模板是先做文档解析再做风险识别再做建议生成最后做结果汇总。动态调整是指根据槽位的具体值对模板做增删改。比如用户指定了focus_areas就在风险识别任务里加上这些关注点用户没指定output_format就用默认格式。这里有个坑任务拆解的粒度要适中。拆得太粗下游代理干不了拆得太细代理之间的通信开销会爆炸。我的经验是每个子任务的预期执行时间在10秒到2分钟之间比较合适太短了不值得单独起一个代理太长了容易超时。3.2 调度层怎么做依赖管理和拓扑排序调度层拿到任务图之后第一件事是做拓扑排序确定任务的执行顺序。拓扑排序的输入是任务列表和依赖关系输出是一个有序的任务序列保证每个任务执行时它的所有前置任务都已经完成。我用的是Kahn算法逻辑很简单先找出所有入度为0的任务没有前置依赖的把它们放进就绪队列然后依次从队列里取出任务执行执行完后把它所有后继任务的入度减1如果某个后继任务的入度变成0就把它加入就绪队列重复这个过程直到队列为空。如果最后还有任务没被执行说明图里有环需要报错。拓扑排序解决的是顺序问题但实际调度中还有并发问题。有些任务之间没有依赖关系可以并行执行。我的做法是每一轮从就绪队列里取出所有任务并行分派给执行代理等这一轮全部完成后再进入下一轮。这样既保证了依赖关系又利用了并发。3.3 失败重试和降级策略任务卡住了怎么办多代理系统里任务失败是常态而不是异常。失败的原因有很多代理超时、代理返回格式错误、代理内部报错、网络抖动。我的策略是分级处理。第一级是重试。对于超时和网络抖动这类瞬时故障直接重试最多重试3次每次重试的间隔指数退避1秒、2秒、4秒。重试时尽量换一个代理实例避免同一个实例连续失败。第二级是降级。对于重试3次仍然失败的任务触发降级。降级的方式取决于任务类型。如果是风险识别任务失败了降级方案是用一个更简单的规则引擎做兜底虽然精度低但至少能出结果。如果是建议生成任务失败了降级方案是直接返回风险清单告诉用户建议生成暂时不可用。第三级是熔断。如果某个代理的失败率超过阈值我设的是50%调度层会把它熔断一段时间内不再分派任务给它。熔断期间定期探测如果探测成功就恢复。def dispatch_with_retry(task, max_retries3): for attempt in range(max_retries): try: agent select_agent(task.task_type) result agent.execute(task) if validate_result(result): return result except (TimeoutError, NetworkError) as e: wait_time 2 ** attempt time.sleep(wait_time) except AgentInternalError as e: break return fallback(task)这段代码是我实际用的简化版。关键点是select_agent每次重试都重新选代理validate_result做结果校验fallback是降级逻辑。实测下来加了这套机制之后任务成功率从85%左右提升到了99%以上。3.4 上下文传递代理之间怎么共享信息多代理系统里代理之间需要共享上下文。比如风险识别代理识别出了风险点建议生成代理需要知道这些风险点才能给建议。上下文传递有两种方式一种是显式传递把上下文放在任务的payload里另一种是隐式传递把上下文存在一个共享存储里代理通过task_id去取。我两种都用。显式传递适合小数据量、强相关的上下文比如风险清单。隐式传递适合大数据量、弱相关的上下文比如原始文档。显式传递的优点是简单直接缺点是payload会变大而且容易在传递过程中被截断。隐式传递的优点是payload小缺点是引入了共享存储的依赖而且需要管理上下文的生命周期。我的经验是单个payload的大小控制在10KB以内超过这个大小就改用隐式传递。共享存储我用的是Rediskey是task_idvalue是上下文内容设置一个合理的过期时间比如1小时避免内存泄漏。4. 执行代理的设计每个代理都要有人设和边界4.1 代理的提示词工程角色、约束、输出格式执行代理的核心是提示词。我踩过的最大坑是早期提示词写得太客气比如请你分析一下这份文档的风险结果代理有时候分析、有时候不分析、有时候分析一半跑去干别的。后来我把提示词改成了硬约束风格明确告诉代理你是谁、你要做什么、你不能做什么、你的输出必须是什么格式。一个典型的执行代理提示词包含四个部分。角色定义你是一个专业的合同风险分析代理你的唯一职责是识别合同中的风险点。约束条件你只识别风险不给修改建议不评价合同整体质量不输出与风险无关的内容。输出格式你的输出必须是一个JSON数组每个元素包含risk_type、risk_description、severity三个字段。边界说明如果文档内容不足以判断风险输出空数组不要编造。这套提示词模板我用了十几个代理实测下来稳定性很好。关键点是唯一职责和不要编造这两句能显著减少代理的越界行为和幻觉。4.2 代理的输入输出契约schema先行每个执行代理都有明确的输入schema和输出schema。输入schema定义了代理能接受什么参数输出schema定义了代理必须返回什么结构。这两个schema是代理和调度层之间的契约双方都按契约来就不会出现鸡同鸭讲的情况。我用的是JSON Schema来定义契约。比如风险分析代理的输入schema定义了document字符串必填、focus_areas字符串数组可选、max_risks整数可选默认10。输出schema定义了risks对象数组每个对象包含risk_type、risk_description、severity。schema先行有个好处代理的实现可以换只要schema不变调度层就不用改。我后来把风险分析代理从GPT换成了本地模型因为schema没变调度层完全无感知。4.3 代理的隔离与资源控制别让一个代理拖垮整个系统多代理系统里一个代理出问题不能影响其他代理。我做了几层隔离。第一层是进程隔离每个代理跑在独立的进程里一个代理崩溃不会影响其他代理。第二层是资源限制每个代理有独立的token配额和并发限制防止某个代理把资源吃光。第三层是超时控制每个代理的调用都有超时超时就被强制中断。资源控制这块我踩过一个坑早期没有限制并发结果一个批量文档分析任务同时起了50个代理实例把API配额瞬间打满导致其他任务全部失败。后来加了并发限制每个代理类型最多同时跑5个实例超出的任务排队等待。这个限制可以根据实际配额调整但一定要有。4.4 本地模型和云端模型的混合部署我的系统里既有云端模型比如GPT-4、Claude也有本地模型比如Llama、Qwen。混合部署的原因是成本和隐私的权衡。云端模型能力强但贵本地模型便宜但能力弱。我的策略是对能力要求高的任务比如风险识别、建议生成用云端模型对能力要求低的任务比如格式转换、简单分类用本地模型。混合部署的挑战是接口不统一。云端模型有标准的API本地模型可能是vLLM、Ollama、或者自己写的推理服务接口各不相同。我的做法是在执行代理和模型之间加一层适配器适配器负责把统一的调用请求转换成各个模型的实际接口。这样执行代理只需要调用适配器不用关心底层是什么模型。实测下来本地模型在简单任务上的表现已经够用了而且延迟比云端模型低很多。如果你的场景对延迟敏感可以考虑把更多任务下沉到本地模型。5. 审核层与结果整合最后一道防线5.1 审核代理的职责查什么、怎么查审核代理是整个链路的最后一道防线。它的职责是检查执行代理的输出是否符合要求、是否自相矛盾、是否遗漏了关键信息。审核代理的检查项包括格式检查输出是否符合schema、完整性检查是否覆盖了所有要求的点、一致性检查不同代理的输出之间是否矛盾、合理性检查输出是否明显不合理。审核代理的实现方式有两种。一种是规则审核用代码写死检查逻辑比如风险清单不能为空、建议必须对应至少一条风险。另一种是模型审核用另一个大模型来检查输出的质量。我两种都用规则审核做第一道过滤快速筛掉明显不合格的输出模型审核做第二道过滤检查那些规则覆盖不到的语义问题。模型审核的提示词很关键。我用的模板是你是一个严格的审核代理。你的任务是检查以下输出是否符合要求。要求是[具体要求]。输出是[待审核内容]。请逐条检查如果发现问题指出具体问题如果没有问题返回PASS。5.2 结果整合把多个代理的输出拼成一份用户能看懂的回复审核通过之后结果整合代理负责把多个执行代理的输出拼成一份完整的回复。这个拼装不是简单的字符串拼接而是要根据用户的原始意图组织成一个有逻辑、有层次的结构。我的做法是结果整合代理的输入包括用户的原始输入、任务图、各个执行代理的输出。它的任务是生成一份用户视角的回复而不是系统视角的报告。所谓用户视角就是用户关心什么就突出什么用户不关心的技术细节就省略。举个例子。用户问帮我分析这份合同的风险系统内部可能跑了文档解析、风险识别、建议生成、合规检查四个代理。但用户看到的回复应该是先给一个风险概览有几个高风险、几个中风险再逐条列出风险点和对应的建议最后给一个整体评价。文档解析的过程、合规检查的细节用户不需要知道。5.3 人工介入的接口设计什么时候需要人来看一眼多代理系统再智能也有搞不定的时候。这时候需要人工介入。人工介入的触发条件我设了几个审核代理连续两次不通过、执行代理返回了低置信度的结果、任务涉及高风险操作比如自动发送邮件、自动修改文件。人工介入的接口设计要考虑两点一是让人能快速理解当前的状态二是让人能方便地修改和继续。我的做法是当触发人工介入时系统暂停任务生成一份介入请求包含任务背景、当前进展、待决策的问题、可选的决策选项。人工处理后系统从暂停点继续执行。这个机制我实测下来触发频率大概在5%左右大部分任务还是能自动完成的。但这5%的介入能显著提升用户对系统的信任度因为用户知道系统搞不定的时候会找人而不是硬着头皮瞎搞。6. 实测中踩过的坑和对应的解法6.1 代理死锁A等BB等A死锁是我遇到的第一个严重问题。场景是这样的任务A依赖任务B的输出任务B又依赖任务A的输出两个任务互相等整个链路就卡住了。根因是任务拆解时没有做依赖检查生成了一个有环的任务图。解法是在调度层加一个环检测。每次生成任务图后先跑一遍拓扑排序如果排序结果的数量小于任务总数说明有环直接报错并触发重新拆解。重新拆解时给入口代理的提示词里加上避免循环依赖的约束。这个坑的教训是不要信任上游代理的输出调度层必须做校验。上游代理再聪明也可能犯错调度层是最后一道关卡。6.2 上下文爆炸token越用越多最后超限第二个坑是上下文爆炸。多代理系统里每个代理的输出都会成为下游代理的输入上下文像滚雪球一样越滚越大。跑到最后一个任务的上下文可能超过模型的token上限直接报错。解法是上下文压缩。每个代理在输出结果时同时输出一个摘要版本摘要版本只保留关键信息去掉冗余内容。下游代理默认使用摘要版本只有在需要细节时才去取完整版本。摘要版本的大小控制在完整版本的20%以内。另外我还加了一个上下文预算机制。每个任务有一个token预算调度层在分派任务时检查剩余预算如果预算不足就触发压缩或降级。这个机制能防止单个任务把整个系统的token配额吃光。6.3 代理偷懒输出敷衍了事第三个坑是代理偷懒。有些代理在遇到复杂任务时会输出一些笼统的、敷衍的结果比如该合同存在一定风险建议仔细审查。这种输出格式上没问题但内容上毫无价值。解法是加具体性检查。审核代理会检查输出是否包含具体的、可操作的信息。比如风险描述必须包含具体的条款引用建议必须包含具体的修改动作。如果检查不通过打回重做并在提示词里强调必须具体。这个坑的教训是代理的提示词里一定要有反敷衍的约束。我后来在所有执行代理的提示词里都加了一句如果你的输出可以被套用到任何一份类似的文档上说明你的输出不够具体请重新分析。6.4 模型幻觉代理编造了不存在的信息第四个坑是幻觉。代理在分析文档时有时候会编造一些文档里根本没有的内容。比如文档里没写违约金比例代理却输出违约金比例为10%。这种幻觉在风险分析场景里是致命的。解法是加溯源检查。要求代理在输出每个结论时同时输出这个结论的依据比如引用的原文片段。审核代理检查依据是否真实存在于原始文档中。如果依据不存在判定为幻觉打回重做。这个机制增加了代理的输出负担但显著降低了幻觉率。我实测下来加了溯源检查之后幻觉率从8%左右降到了1%以下。6.5 性能瓶颈调度层成了单点第五个坑是性能瓶颈。随着任务量增加调度层成了单点所有任务都要经过它它一卡整个系统就卡。解法是把调度层做成无状态的可以水平扩展。调度层的状态任务图、执行状态存在Redis里多个调度层实例共享这些状态。任务分派时通过一致性哈希把任务路由到固定的调度层实例避免状态冲突。这个改造花了不少时间但效果很明显。改造前系统最多支撑每秒10个任务改造后能支撑每秒100个以上。7. 内容合规与安全边界多代理系统不能碰的红线7.1 为什么多代理系统的合规风险比单代理更高多代理系统的合规风险比单代理高原因是攻击面更大。单代理系统只有一个入口你只需要在入口做过滤。多代理系统有多个代理、多条通信链路、多个输出点任何一个环节出问题都可能导致合规事故。具体来说风险点包括入口代理被诱导生成不当内容、执行代理在处理文档时接触到敏感信息、代理之间的通信被截获、结果整合时把不当内容拼进了最终回复。这些风险点都需要单独设防。7.2 输入过滤、输出过滤、代理间通信过滤我的做法是在三个位置做过滤。输入过滤在入口代理之前检查用户输入是否包含明显的不当内容如果有就拒绝处理。输出过滤在结果整合之后检查最终回复是否符合规范如果有问题就拦截并返回标准话术。代理间通信过滤在每个代理的输入输出处检查传递的内容是否合规。三层过滤的核心逻辑是一样的用规则模型双重检查。规则检查快速筛掉明显违规的内容模型检查处理那些规则覆盖不到的语义问题。模型检查用的提示词是请判断以下内容是否包含不当信息。如果不包含返回SAFE如果包含返回UNSAFE并说明原因。7.3 审计日志出了事能查到是哪一步出的问题多代理系统必须要有完整的审计日志。每个任务的每一步操作都要记录谁发起的、什么时间、调用了哪个代理、输入是什么、输出是什么、耗时多少、是否成功。这些日志不仅是排查问题的依据也是合规审计的依据。我用的是结构化日志每条日志是一个JSON对象包含timestamp、task_id、agent_id、action、input_summary、output_summary、duration_ms、status。日志存在Elasticsearch里方便检索和分析。审计日志的存储要注意隐私保护。输入输出里可能包含敏感信息存储时要脱敏比如把身份证号、手机号替换成占位符。8. 从这套架构里提炼出的几条硬经验8.1 结构化优于自然语言契约优于默契这是我最深的一条体会。多代理系统里代理之间的接口比代理本身的智能更重要。自然语言通信看起来灵活实际上是不稳定的根源。结构化消息JSON Schema契约虽然写起来麻烦但能省掉后面无数的调试时间。8.2 每个代理只做一件事并且做到极致代理的职责越单一输出质量越稳定。我试过让一个代理同时做风险识别和建议生成结果两个都做不好。拆成两个代理之后每个都做得很好。这个道理跟微服务架构是一样的单一职责原则在多代理系统里同样适用。8.3 审核和溯源是质量的最后保障不要信任任何一个代理的输出包括入口代理。审核层和溯源机制是质量的最后保障。虽然它们会增加系统的复杂度和延迟但相比输出错误带来的后果这个代价是值得的。8.4 可观测性不是可选项是必选项多代理系统的调试难度比单代理高一个数量级因为没有可观测性你根本不知道问题出在哪一层。日志、链路追踪、指标监控这三样东西必须从第一天就做不能等出了问题再补。8.5 合规和安全要从架构层面解决不能靠事后补救合规和安全不能靠出了事再改必须从架构层面就设计进去。输入过滤、输出过滤、代理间通信过滤、审计日志这些机制要在系统设计阶段就考虑而不是等上线了再打补丁。这套系统我前后迭代了大概半年从最初的demo到现在的生产可用中间推翻重来了好几次。最大的感受是多代理系统的难点不在AI在工程。AI的能力决定了系统的上限但工程的质量决定了系统的下限。把工程做扎实AI的能力才能稳定地发挥出来。