AI Agent 总是执行失败？问题出在大模型还是 Agent Harness

AI Agent 为什么总是执行失败，甚至反复调用工具却做不完任务？先不要急着换更贵的大模型：如果问题来自工具选错、分页漏取、上下文截断、超时重试、未经授权的写入，或者没有检查结果就宣布完成，更强模型也不能替代可靠的执行控制。Agent Harness（智能体运行层）负责工具调用、状态管理、审批、错误恢复和结果验证；先定位失败发生在模型推理还是执行系统，才能决定优化哪一层。本文结合真实论文与五项小型模拟控制回放，给出可用于工程排查的判断方法，并明确哪些结论还没有经过本站模型实测。

如果一个 AI Agent 在简单问答中表现不错，一旦要跨页面检索、分页读取 API、更新数据、调用命令和验证结果，完成率就急剧下降，你首先应该换一款更强的模型，还是检查包在模型外面的执行系统？这个问题不能凭模型排行榜回答。模型负责理解、推理和决策；Harness（智能体执行运行层）负责把任务变成有状态、有工具权限、有失败处理、有验收结果的实际行动。二者都会影响结果，但先优化哪一层，取决于失败究竟来自推理不足还是执行链断裂。

2026 年 11 月 3 日，IBM Research 在 Hugging Face 发表了一组很有冲击力的数据：同一 GLM-5.3-flash 模型，分别交给 CUGA、Hermes、Deep Agents 执行 AppWorld 的 90 项任务，三者分别完成 73、42 和 27 项，也就是 81.1%、46.7% 和 30.0%。这不是说 CUGA 永远比其他 Harness 强，更不是说换模型不再有意义。IBM 自己就说明，三套配置并不一致、每项只尝试一次、只覆盖一个基准，而且没有在该轮任务中测试策略约束。真正重要的是：模型权重不变，执行系统的不同足以让同一组任务出现巨大结果差异。IBM Research，2026-11-03

本文不是换一批产品名字重写“什么是 Agent Harness”。XBSTACK 已有 DeepSeek V4-Pro 与 DeepSeek Harness 介绍，也讨论过 OpenAI Agents API、Agents SDK 与 Responses API 的控制权分工。这一次只做一件事：先把外部可验证的同模型对照研究拆开，找出最容易被误读的地方；然后以五项可运行、可复核的执行失败回放，说明哪些问题即使换了模型也不应该交给模型自由发挥；最后提供一套可直接用于真实项目的“是否该换模型”决策和对照实验协议。

30% 到 81%：同一个模型为什么会跑出三份不同成绩

先看实验究竟比较了什么。IBM 选择 AppWorld，一个模拟多应用操作的任务集，涉及邮件、付款和文件存储等 9 个应用、457 个 API。实验使用其中 30 个场景、90 项任务，保持模型为 GLM-5.3-flash，每题一次，统一由 Harbor 框架评估。CUGA 的配置包含按应用分解任务、先验证再执行、自动反思、聚焦工具和工具搜索；Hermes 使用 Harbor 的默认设置，通过 MCP 暴露 AppWorld 工具；Deep Agents 使用工具搜索、上下文摘要、待办列表、重试和调用上限等 Middleware，研究者还为格式异常回复加了两个小修补。

图 1｜固定模型、改变运行层可能产生不同执行路径。为结构概念图，非 IBM AppWorld 实际结果截图。

该研究中的 Harness	通过任务 TGC	完成全部三种变体的场景 SGC	需要读懂的限制
CUGA	73/90（81.1%）	20/30（66.7%）	配置针对 AppWorld 设计，包含特定拆解和校验
Hermes	42/90（46.7%）	8/30（26.7%）	默认配置更偏常驻个人助手场景
Deep Agents	27/90（30.0%）	2/30（6.7%）	面向通用长任务的 Middleware，并非专门为该基准优化

TGC 统计单项任务通过数量，SGC 则要求一个场景的三个变体全部成功。后者有助于观察同一类任务能否稳定通过，而不是偶然对一道题奏效。IBM 公开了实验配置链接，复核者可以尝试在相同任务上调整其他 Harness。值得注意的是，即使固定了模型，Harness 自身的配置不同也是比较变量的一部分。它不等于在严格相同的提示词、工具描述、上下文组织、预算和错误处理条件下只替换一个“产品名称”。因此这项研究可以支持“执行系统会显著影响完成率”，却不能把所有差距归因于某一个具体 Middleware，更不能据此推导其他模型、企业环境或编程任务的排名。

当一套系统接入 469 个可用工具时，它在每一轮给模型暴露多少工具、如何缩小候选、何时检查分页、哪一步可以执行写操作，都会改变模型看到的问题难度。模型并不是每次都面对同一个选择空间。假如 A 运行时会提前筛选出 8 个相关工具，B 运行时直接暴露几百个定义，那么“同一模型”的确成立，但它接收到的上下文和行动空间已经不同。这既是 Harness 可以发挥价值的机制，也是评测需要披露差异的原因。

IBM 文章里还有一个特别容易被误读的安全结论。CUGA 提供 Tool Approval、ToolGuard 等策略控制点，但上述 90 任务没有启用策略测试。任务完成率高，不自动等于授权隔离更安全、隐私更好，也不等于付款之类的副作用一定可控。 这些必须通过独立的拒绝访问、审批暂停、撤销与审计测试证明。把“有这个组件”当成“这个基准已经验证安全性”，会把工程方案最关键的证据门槛抹掉。

别只看一份厂商实验：另一批研究给出了不同答案

同模型切换 Harness 会改变表现，并不是 IBM 独有观察。Composio 公开的 Harness 与 Connector 对照覆盖约 1,800 次试验，其中 DeepSeek V4 Pro 的 30 项任务设置下，不同 Harness 成功率分布为 30%—60%；在 GPT-6 Astra 的另一组 29 项可比任务中，六个 Harness 的成功率区间却只有约 66%—72%。Composio 还记录到很大的成本差距，但部分 Harness 的用量数据覆盖任务数不等，个别价格为估算而不是实际账单。不能把成本倍数直接当成同一任务、相同计费口径下的普遍规律。Composio 研究与方法说明

另一份 2026 年 8 月预印本 Same Model, Different Harness: Different Coding-Agent Results 提供了更接近“只改执行策略”的证据：作者保持模型权重与任务不变，仅让旧工具记录在接近上下文上限时机械裁剪，并对重复卡住的执行给出反馈。在 SWE-bench Verified 的 169 题紧上下文设置（20,480 token、每题 480 秒）中，完整解题数由 43 增至 72；但作者也指出，宽上下文下部分任务的差距显著缩小。它表明 Harness 改造的收益可能集中在上下文受限与流程卡住的场景，并不能把某一种策略推广为总有收益的通用优化。这里引用的是公开预印本数据，不是 XBSTACK 的复现实验。

同一个 Harness 在某个模型上排名靠前，换一款模型后位置可能掉下去，这是比“哪个 Harness 第一”更重要的发现。论文 Finding the Right Fit 针对多种模型、Harness 和任务基准构造了 66 种配置；在 Terminal-Bench 4 上，Claude 与 GPT 的相对差距会随着 OpenHands 和 PI 等执行层改变而出现方向反转。这不意味着某款模型“被误测”，而是模型产生动作、理解工具错误、使用上下文和自我修复的习惯，与运行层提供的接口之间存在交互。选择时必须评估 模型 × Harness × 任务类型 这个组合，而不是单独给模型和 Harness 各贴一个等级。

还有一篇值得并列阅读的污染控制研究 Harness or Model?：研究者在同模型、同题目的成对实验中比较原生 SDK 与 Deep Agents，在所报告的平均结果上，没有得到可确认的一方显著优于另一方的证据。例如 GPT-5.5 的两组结果约为 55.6% 与 54.4%，差异的置信区间跨过零；Opus 4.8 的对照也没有证明稳定的平均优势。某些任务子集可能呈现相反方向的差别。这提醒我们：“Harness 有影响”与“任何时候先换 Harness 都更划算”是两件完全不同的命题。前者已有大量支持，后者还需要每个团队自己的任务与成本证据。

2026 年 10 月的论文 When Agents Fail: Model or Harness—Who’s to Blame? 进一步提出 Valid Completion Rate（有效完成率，指运行正常结束且产物可评分，不一定答对）与最终任务正确率应当分开记录。它强调有的系统能顺利返回结果却答错，有的任务虽被运行超时中断，却已经生成可通过测试的补丁。把所有失败都丢进一个“成功率”字段，会让人根本分不清问题在思考、工具、结束状态还是验证器。

什么是 Harness 失效，什么才是模型能力不足

为了决定该优化哪一层，可以沿着任务链逐项追问。第一种是模型本身选错了目标：输入信息齐全，工具调用也执行成功，模型仍然不能理解用户真实意图、生成错误的 SQL 或代码逻辑。这可能需要更好的问题表述、领域示例、检索证据，若经过控制后仍失败，才更有理由升级模型。第二种是工具和上下文接口的问题：正确工具没有被暴露，参数 Schema 描述含糊，网页结果截断但未告知，模型拿到的资料不完整。此时直接换模型，仍可能让更强模型在错误输入上作出自信结论。

图 3｜分层诊断清单：先定位失败发生在哪一层，再决定换模型还是修执行流程。

第三种是状态和恢复问题：请求超时后 Harness 不知道操作到底是否成功，重试重复创建订单；子任务已经修改文件，主任务却只拿到“执行完成”字样；会话压缩后遗失先前人工批准或撤销的决定。这些问题的底线不是模型智力，而是幂等键、事务边界、持久化状态机、可观察的错误类型和可靠的恢复协议。第四种是授权与副作用问题：用户只要求出方案，模型却能直接调用删除、付款、发布、写入生产数据库等工具。无论模型多么擅长服从提示词，都不应让“请别删”这类自然语言指令代替服务端硬授权与暂停审批。

第五种是验证器缺失：AI Agent 告诉你“已修复”“已上线”“全部推送成功”，但它没有跑测试，也没有检查公开 URL、Build 结果、第三方最终状态。这类错误很容易在演示中被掩盖，因为模型产生的解释文字看起来已经完整。一个工程 Harness 应要求证据指向特定命令退出码、状态变化、部署记录或可重复的验收结果；如果只记录自然语言答案，再好的大模型也可能把“它认为完成”混同“事实上完成”。

失败表现	先核查哪一层	必须补充的验证	何时再考虑换模型
工具没找到、错选工具	Tool Search、Schema 与上下文筛选	正确工具是否可见、参数是否可解	接口稳定仍持续误选
分页未完成、结果截断	分页状态与 truncated 标志	总数/游标/末页是否核对	完整数据仍无法正确推理
超时后重复写入	幂等、Retry、Checkpoint	中途断开、恢复、重试测试	状态机安全但决策持续错误
未授权删除或付款	服务端策略与人工审批	拒绝是否确实阻断工具执行	不应只靠换模型补救
说已修复却未运行测试	构建/验收器与 Evidence Gate	日志、Diff、真实公开状态	验证充分仍产出错误修改
明确证据齐全却不能规划	任务分解、Prompt 与模型推理	同输入重复运行、人工基线	推理能力可能已成为瓶颈

还有一类“Agent 做不完任务”的问题发生在模型 API 适配层，而不是模型权重或复杂的编排策略。火山方舟在 2026 年 11 月更新的 Agent 模型调用实践 明确列出：多轮工具调用时没有正确回传需要保留的思考内容、输出 token 上限过小导致 finish_reason 为 length、同一会话频繁改变工具定义与采样参数影响缓存命中，都可能造成表现下滑。对这些问题，第一步应按具体提供商的协议检查请求、响应和轮次回传，再谈重做 Harness 或换模型；不同厂商对思考内容的可回传形式、隐私和存储约束并不相同，不能直接照搬某一家参数设置。Anthropic 的长任务 Harness 设计复盘还指出，任务拉长时上下文压缩未必足以防止提前收工，受控状态交接与上下文重启也是值得对比的执行策略。两项都是外部公开实践，不是本站对所有模型的统一实测结论。

XBSTACK 做了什么：五项没有大模型参与的故障回放

为了把这些问题从纸面概念变成可以检查的程序行为，我在 XBSTACK 工作区新增了 experiments/agent-harness-vs-model-20261104/harness-replay.mjs。这不是一个伪装成模型跑分的演示。它没有调用 OpenAI、DeepSeek、Gemini、Claude，也没有安装并实测 IBM CUGA、Hermes 或 Deep Agents。程序使用预先写好的相同任务动作和模拟工具响应，让一套极简运行层与一套加入控制规则的运行层分别处理五种故障，再由同一个断言检查结果。它的用途仅仅是证明五个运行机制的行为差异是可执行、可复核的，而不是估计任何商业 Agent 的总体完成率。

第一项测试模拟分页账单：API 第一页只有两条，第二页还有一条。极简执行路径直接接受第一页，控制路径看到还有数据就继续取回第二页；验收器不检查“回答看起来是否自然”，只判断最终是否包含三个预先定义的 ID。第二项是未经审批的删除动作：输入要求准备一个删除方案，模型拟议了删除调用，但用户并未授权执行。极简路径调用了有副作用的工具，受控路径只返回需要审批。这里不测试提示词能否诱导模型听话，而是测试工具执行边界能否从模型输出之外硬性建立。

第三项是读取请求第一次超时、第二次成功。受控路径在确认它属于可以安全重复的只读请求后重试；极简路径结束为错误。这不能被推广为“遇到超时自动重试所有工具”。写入支付、下单或不可逆发布时，必须先确认幂等键、远端状态与用户授权，否则重试反而制造第二次副作用。第四项模拟工具返回 truncated:true，极简路径把不完整结果视为成功，受控路径补取完整数据。第五项模拟最终报告声称“99% 通过率”，而证据只有 93%，控制路径拒绝无出处数字，返回带证据引用的 93%。

运行命令和断言结果可以独立核对：

node experiments/agent-harness-vs-model-20261104/harness-replay.mjs
# {"cases":5,"baselinePassed":0,"guardedPassed":5}
# All assertions passed. Read replay-results.json for per-case evidence and limits.

这里出现的 0/5 与 5/5 是五个专门构造的模拟故障的断言结果，不是所谓“普通 Harness 0% 成功、高级 Harness 100% 成功”；也没有统计意义上的模型性能差异。程序刻意让受控路径满足这些事先定义的规则，所以其结果只能说明实现了预期的检测、重试、拦截、分页和证据检查。完整运行记录保存在 replay-results.json，并附有这一限制声明。把这组数字当成真实 LLM 准确率、生产安全率或成本收益率都是错误的。

这项小实验的价值在于帮助团队写出自己的验收器。比如对 XBSTACK 网站运营，搜索引擎接受一条 URL 提交不能算已经收录；浏览器编辑器里有文章不等于正式公开；构建通过也不代表所有关键路由可用。如果执行系统只等待模型说“完成”，就会出现大量漂亮但无法追溯的结论。把真实验收信号接入流程，才是值得优化的 Harness 部分。不过，本实验没有触及真实平台权限、网络失败概率或长期 Agent 任务，因此不能把这些机制局部通过写成整条业务链已经通过。

真正比较“换模型”和“改 Harness”，要做一张 2×2 对照矩阵

要回答标题里的“哪个更值得优先投入”，必须把两种优化做成可分辨的实验因素。假定已有模型 A 和候选升级模型 B，以及当前 Harness H0 和改善后的 Harness H1，就形成 A×H0、A×H1、B×H0、B×H1 四个单元。三组固定任务分别测：一项真实仓库的代码修改及测试，一项跨 API 工具检索与安全写入，一项长时间任务的中断和恢复。每组任务使用相同初始快照、工具权限和数据，至少多次重复，保存模型版本、运行时 Commit、Prompt、预算、人工介入和全部结果，不允许只上传最好的一次。

图 4｜这张图的“验证完成率”指通过独立验收的完成比例，不等于研究论文中“正常结束且可评分”的 Valid Completion Rate（VCR）；两项必须分别统计。

图 2｜四组对照是待执行的评估设计，不是 XBSTACK 已完成的跨模型跑分。

第一条对比是 A×H0 与 A×H1，估计同一个模型下 Harness 改造的效果；第二条是 A×H0 与 B×H0，估计不修改 Harness、只升级模型的效果。第三条很容易被忽略：B×H1 相对 B×H0 可能受益，也可能因为两个组件不适配而更差。只有把四组都跑出来，才知道“先升级模型”是否真正更划算，还是当前系统只是把工具、上下文或错误信号处理坏了。

实验单元	模型	Harness	能支持的判断
A / H0	现用模型	旧运行层	当前真实基线
A / H1	现用模型	改进运行层	Harness 改造增量
B / H0	新模型	旧运行层	纯模型升级增量
B / H1	新模型	改进运行层	交互效果与组合上限

同样重要的是评分规则。任务通过率必须来自程序验证、明确人工复核标准或独立评估器；“能正常结束”的 Valid Completion Rate 不能当成“任务正确”；任何未授权副作用、错误写入和凭据外泄都应独立计数，即使最终回答看起来正确也不能抹掉。成本既记录 Token、缓存与实际模型费用，也要记录总工具次数、运行时长、必要的人工作业与失败重试。更稳妥的经营指标是 Cost per Validated Task（每个已验证正确任务的成本），用总成本除以通过独立验收的任务数，分母必须为真实成功结果，不能用全部请求数稀释成本。

需要特别防范一个方法学陷阱：如果 H1 的新配置是研究者根据同一套公开问题反复调试出来的，再用这些问题证明 H1 进步，就可能只是对这批题过拟合。应该保留未参与优化的任务族，并在测试时冻结提示词、代码和评估器；否则多花推理和反馈预算也会让结果更好，却被错误归功于 Harness 设计。Rethinking the Evaluation of Harness Evolution 提醒过这个问题。

先做哪些 Harness 改造，才可能有真实回报

我会按故障风险和改造收益排序，而不是见到“自我进化 Agent”就替换整套执行器。第一优先级是授权与结果验收。凡涉及删除、付款、发布、生产数据库和私有资料外发，策略必须在可信边界检查工具名、参数、用户授权、资源范围和审计事件；允许模型提出建议，不允许模型单靠一句自然语言解释给自己授予执行权。对普通工程任务，应让测试、构建、静态校验和实际状态核查成为“完成”的必要条件。这里投入不一定提高一次生成的漂亮程度，却能直接减少代价高昂的误操作与虚假完成。

第二优先级是 Tool Interface：逐个检查工具描述、参数类型、失败码、游标、截断标志、目标资源和副作用语义。能用一个清晰、窄范围的工具解决，就不要一次暴露几十个看似相似的动作；能返回结构化 tool_error 与 retryable，就不要把所有错误压成“操作失败，请重试”。模型需要的不是更多工具名称，而是下一步可判断的有效信号。模型反复选错工具时，先做一组工具选择准确性测试，再决定是改工具设计还是换模型。

第三优先级才是上下文工程和长任务管理。重要事实、指令、用户许可和证据来源应以可恢复记录保存，压缩上下文不得悄悄改变用户授权或抹掉执行结果；真正耗费 Token 的大日志可以在文件侧聚合后仅把关键异常返回给模型。第四优先级是失败恢复与资源调度：Checkpoint 恢复要考虑副作用已发生但本地状态未落盘，重试要考虑幂等，时间预算和取消动作也需要稳定语义。更复杂的多 Agent 分工、自动 Skill 选择和自优化 Harness，应该在前四层可观察且能回滚以后再引入，否则很容易把一个问题扩展成多个难以诊断的故障。

五个典型场景，什么时候应该立即换模型

有些团队当前的瓶颈确实不在 Harness。比如代码库规模和工具输入都合理，测试日志完整，Agent 能正确找到文件、运行测试并接收明确失败反馈，但它仍长期无法理解复杂算法、不同业务规则的冲突或跨组件时序问题。你可以通过人工给出同一组有效上下文让几个候选模型直接回答，并在相同校验下比较，判断是不是模型推理能力到了边界。这个时候继续堆 Middleware 也许只增加延迟，真正需要的是更强模型、任务拆分或者专用求解方法。

又比如多语言资料的知识检索，文档导入、切块、FTS、Embedding、Rerank 和证据片段选择已经稳定，引用也指向正确原文，但模型总是把限定条件总结错、生成矛盾答案。这属于可以尝试升级生成模型或改变模型路由的情况。反过来，如果问答失真来自检索漏掉了关键片段，或者来源引用在上一轮对话后丢失，那么直接换生成模型不会自动把证据找回来；需要先修召回和 Evidence Selection。对 Personal AI / Local RAG 产品尤其如此，模型规格不能代替证据链质量。

再比如一个 Coding Agent 能稳定返回完整 Diff，静态检查与单元测试都能运行，失败来自它无法在多步修改中保持抽象层次、持续引入回归；此时在同一 Harness 下比较不同模型、不同推理预算、单 Agent 和多阶段 review，是合理的模型升级实验。相反，如果所有模型都在工具执行时被环境权限、路径错误或错误状态卡住，就不该一再付更高的推理费用去解释同一段基础设施故障。

新方向：Harness 可能自己改进，但更要谨慎验收

Agent Harness 不再只是一组手写提示词。Google 研究团队公开的 Harness² 提出两层递归：任务内提出候选配置、试跑并比较；跨任务再整理经验，供后续 Harness 使用。论文报告在特定基准和模型组合上存在增益，代码可在 google-research/harness2 查看。它对开发者的启发并不是“以后不用写 Harness”，而是配置、工具说明、Skills、子任务组织可以成为持续实验的对象。但优化器自己反复看到的题目不能再直接当作独立验收集，自动化试跑也需要预算、权限和回滚边界。

另一条方向是将轻量决策模型嵌入 Harness，处理某些工具选择或简单路由，同时把困难状态留给主模型。论文 JevAgentHarness 报告了任务相关的成本与速度改善，但不同负载、置信度门限和训练分布都会改变风险。真实团队不应只把它理解成“用小模型省钱”；如果决策模型在错误状态下高置信度选择了有副作用的工具，所谓节省可能变成更高的业务损失。推理加速要与安全约束、校验器和失败成本一起核算。

这些研究同时揭示了一个有趣的方向：未来的 Agent 产品不一定靠每一步调用最大的模型竞争，而可能靠“对该任务最合适的模型 × 有证据约束的 Harness × 可回滚的业务流程”竞争。 这仍然是一个需要在生产任务上验证的技术趋势，不是对所有产品通用的赢家名单。XBSTACK 当前更合适的动作是复用已有 Agent 安全、LangGraph、MCP、RecalAI 与工具链资产，沉淀小而可靠的实验，而不是因为出现一个新论文就匆忙增加一个没人维护的工具页面。

结论：不是先换模型或先改 Harness，而是先找出失败发生的层

我的决策顺序很简单。若 Agent 的错误来自分页、截断、无效工具 Schema、授权、幂等、重试、Checkpoint 或“没验收却宣布完成”，先优化 Harness；若工具、证据、状态与验收都稳定，而在相同任务输入下仍持续出现理解和推理错误，优先比较模型；若两者同时有问题，就做 2×2 矩阵，而不是在新模型上叠加新 Harness 后，把全部收益算给其中一个。任何一次改动都应留有回滚方案和相同任务的前后结果。

IBM 的 30%—81% 很值得关注，但那是特定模型、特定基准与特定配置下的外部研究；另一批独立研究也显示 Harness 排名会随任务和模型反转。XBSTACK 的五项本地回放只验证了几项基础控制机制，尚未进行真实模型 A/B、CUGA/Hermes/Deep Agents 实机横评、商业 API 成本比较或生产安全审计。这条证据边界比一个整齐的“最强 Harness 排行榜”更重要。只有把要完成的用户任务、失败代价、执行证据和每次验证成本一起放到桌面上，才有资格回答“哪一种优化更值”。

参考资料

• IBM Research，Same Model, Different Harness（2026-11-03）
• Composio，Harness and connector choices across 1,800 trials
• Same Model, Different Harness: Different Coding-Agent Results（2026-08）
• Finding the Right Fit: Model-Harness Interactions across Agent Tasks（2026-10）
• When Agents Fail: Model or Harness—Who’s to Blame?（2026-10）
• Harness or Model? Contamination-Controlled Private Suite（2026-09）
• Rethinking the Evaluation of Harness Evolution（2026-07）
• Harness²：Google Research GitHub 与论文
• OpenAI：Harness Engineering（2026-02）
• XBSTACK 本地可复核脚本：experiments/agent-harness-vs-model-20261104/harness-replay.mjs（仓库内部实验资产；尚无公开 URL，不把本地路径冒充读者可访问链接）

继续阅读

• DeepSeek Harness 的接入及预览状态
• Agents API / Agents SDK / Responses API 的控制权选择
• Agent 工具授权 Policy Gate
• LangGraph Checkpointer 的状态与恢复

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南 订阅