22 道智能体与工作流练习题及答案

Claude 认证开发者（基础级）考试练习的全部智能体与工作流练习题，附正确答案和简短解析。

1. 某支付团队每晚运行一个对账作业：提取当天的账簿记录、进行规范化、与银行文件比对，然后邮件发送差异报告。这四个步骤始终相同、顺序固定，且审计要求每次运行都可复现。哪种架构最合适？
- A.多智能体网络：每个步骤是一个对等智能体，彼此互发消息
- B.由你的代码通过预定义路径编排模型调用的工作流✓ 答案
- C.单次模型调用：把整个账簿粘贴进提示词，不使用任何工具
- D.自主智能体：每晚自行决定运行哪些步骤以及顺序
工作流的定义是：通过预先定义的代码路径来编排大模型与工具；而智能体则由模型动态决定自身流程。本题的步骤已知且固定，业务上要求确定性、可复现性与可审计性，因此控制流应当写在代码里——把这一决策交给模型只会增加延迟、成本与不确定性，却没有相应收益。
编号 QB-UBWX88依据： Anthropic docs — Building Effective Agents: workflows vs. agents报告此题的问题
2. 下列哪项任务最能明确地证明应当构建智能体，而不是由代码编排的工作流？
- A.把一份固定的发票 PDF 列表转换成电子表格的行
- B.把一段产品描述翻译成八种语言
- C.修复陌生代码库中失败的测试套件，步骤无法事先规划✓ 答案
- D.在人工阅读前，把每封收到的支持邮件改写成更友好的语气
选择智能体的四条判据是：复杂度（任务无法事先完全指定）、价值（结果值得更高的成本与延迟）、可行性（模型胜任该类任务）以及错误代价（错误可被发现并恢复）。在陌生代码库中调试满足全部四条——步骤序列确实不可预测，而测试套件提供了可捕获错误改动的环境真实反馈。另外三项都是单次转换，根本不需要工具往返。
编号 QB-CU35U8依据： Anthropic docs — Agent design: should I build an agent?报告此题的问题
3. 某开发者把应用中的每一次模型调用——包括一个纯粹的“总结这篇文章”接口——都包在一个检查 stop_reason 并执行工具的 while 循环里。对于总结接口来说，这样做的问题是什么？
- A.未声明工具的请求不会返回 stop_reason，因此循环无法退出
- B.循环永远不会结束，因为总结任务从不返回 end_turn
- C.即使未定义工具也必须返回工具结果，因此循环会报错
- D.总结不需要工具，因此循环只是徒增代码与延迟✓ 答案
指导原则是：找到能奏效的最简方案，只有在可证明能改善结果时才增加复杂度。总结、翻译和常识问答都是单次调用任务：不需要外部真实反馈，因而不需要工具往返；对于琐碎任务，工具循环的开销甚至可能超过任务本身。该循环并非有错——无工具请求第一轮就会返回 end_turn——它只是多余的机械结构。
编号 QB-VB9AE9依据： Anthropic docs — Agent design: start simple报告此题的问题
4. 某营销团队分三个阶段生成活动文案：先起草大纲，再扩写为正文，最后做本地化。在第一阶段和第二阶段之间，用普通代码检查大纲是否包含必需的法律免责声明，若没有则退回第一阶段。这属于哪种模式？
- A.编排者—工作者，因为协调了三次模型调用
- B.提示链（prompt chaining），并在步骤之间设置程序化关卡✓ 答案
- C.评估者—优化者，因为在两次生成之间运行了检查
- D.并行化中的投票法，因为大纲可能被生成不止一次
提示链把任务分解为固定的步骤序列，每次调用处理上一步的输出，并可在步骤之间设置程序化关卡以在继续前进行校验。与评估者—优化者的区分点在于：这里的检查是执行既定规则的确定性代码，而不是由第二个大模型给出迭代式的定性反馈；与编排者—工作者的区分点在于：这些步骤是预先定义的，而非由模型在运行时决定。
编号 QB-DUEFZ9依据： Anthropic docs — Building Effective Agents: prompt chaining报告此题的问题
5. 一个客服工单队列中混杂着密码重置、账单争议和 API 集成问题。每一类都由不同的提示词处理效果最好，而密码重置足够简单，可交给更便宜、更快的模型。哪种模式合适？
- A.评估者—优化者
- B.带停止条件的自主智能体
- C.并行化中的分段法：同时运行全部三个专家提示词再合并
- D.路由：先对输入分类，再分派到专门的后续提示词或模型✓ 答案
路由把输入分类到不同类别，并将每一类分派给为其专门设计的后续提示词或模型——这也使得简单类别可以走更便宜或更快的模型，而不会拖累困难类别。此处用分段法是错的，因为三个类别互斥：对每张工单都运行三个专家会让成本翻三倍，得到两个被丢弃的答案，而不是把一个任务拆成真正独立的子任务。
编号 QB-WBMMKA依据： Anthropic docs — Building Effective Agents: routing报告此题的问题
6. A 团队用一次模型调用回答用户问题，同时用第二次并发调用对同一输入做违规筛查。B 团队把同一份代码 diff 发给五次相同的评审调用，并汇总有多少次标记出漏洞。按顺序，这分别属于哪种并行化变体？
- A.两者都是投票，只是汇总规则不同
- B.先是分段，后是投票✓ 答案
- C.两者都是分段，只是调用次数不同
- D.先是投票，后是分段
分段法把一个任务拆成可并发运行的独立子任务——回答问题与违规筛查是对同一输入执行的不同工作，带来速度提升与关注点分离。投票法则是对同一任务运行多次以获得多样输出再加以汇总，用于对“diff 是否含漏洞”这类判断性问题建立置信度。判别标准是：并发调用做的是不同的工作（分段）还是重复同样的工作（投票）。
编号 QB-EUSS6B依据： Anthropic docs — Building Effective Agents: parallelization (sectioning and voting)报告此题的问题
7. 某代码迁移系统收到诸如“把这个服务从已弃用的认证库迁移出去”的请求。一个中心模型读取代码库，在运行时决定哪些文件需要修改、由此产生多少个子任务，分派这些子任务，然后综合结果。它与并行化的区别是什么？
- A.它是唯一在最后汇总结果的模式
- B.它要求子任务串行而非并发运行
- C.它使用的模型调用次数总是多于并行化
- D.由模型而非代码在运行时确定子任务✓ 答案
这是编排者—工作者模式。并行化同样会扇出并合并工作，但其子任务在运行前就由开发者固定；而在编排者—工作者中，中心模型在运行时分解任务，因此子任务的数量和形态都无法事先知晓。正是这种运行时分解使它成为二者中更具智能体特征的一方，也使其追踪与审计成本更高。
编号 QB-XBYXRB依据： Anthropic docs — Building Effective Agents: orchestrator-workers报告此题的问题
8. 在基于 Messages API 的自定义智能体循环中，模型返回的响应包含一个简短文本块和两个 tool_use 块。在返回工具结果之前，必须向消息列表中追加什么？
- A.什么都不用追加——仅有 tool_result 用户消息就够了
- B.只追加文本块，因为 API 会根据工具结果重新推导出 tool_use 块
- C.原样追加完整的助手消息——文本块与 tool_use 块一起✓ 答案
- D.追加助手所说内容的摘要，以保持对话精简
循环必须追加助手轮次的完整内容列表，而不仅仅是文本。你回传的 tool_result 块要通过 id 与 tool_use 块配对，因此若丢弃 tool_use 块或用摘要替换，结果就无从配对，请求会被拒绝。逐字保留内容也能确保其他模型内部块类型在多轮之间保持完好。
编号 QB-FU55CC依据： Anthropic docs — Implement tool use: appending the assistant turn报告此题的问题
9. 某团队的智能体循环在助手文本包含“I have completed”时退出，或在十次迭代后退出，以先到者为准。为什么这被视为反模式？
- A.解析文本没问题，但短语必须不区分大小写地匹配
- B.十次迭代太少；正确的固定次数取决于任务
- C.生产环境的智能体循环中绝不允许使用迭代上限
- D.应以 stop_reason 而非文本作为终止信号，迭代上限只是安全护栏✓ 答案
标准循环依据 stop_reason 分支：只要它是 tool_use 就执行工具并重发；其他任何值都结束循环。匹配助手的行文很脆弱，因为模型的措辞不是契约，会在不同响应间变化，因此以短语为准的循环会在生产中悄然失效。迭代上限仍然值得保留，但它应作为叠加在 stop_reason 检查之上的失控护栏，而非主要退出条件。
编号 QB-YBBAXC依据： Anthropic docs — Handling stop reasons in an agent loop报告此题的问题
10. 一个声明了服务端工具的智能体收到一个 stop_reason 为 pause_turn 的响应。正确的处理方式是什么？
- A.追加已暂停的响应后重发，让模型继续✓ 答案
- B.丢弃已暂停的响应，从头重试原始用户消息
- C.把它当作 end_turn 处理，把部分答案返回给用户
- D.追加一条内容为“Continue.”的新用户消息来推动模型继续
服务端工具在 Anthropic 的基础设施上运行其采样循环，并带有内部迭代上限；触及该上限就会产生 pause_turn，表示该轮次尚未完成，而不是已完成。正确做法是把已暂停的助手响应追加到消息列表并重发——API 会检测到末尾的服务端工具块并自动续跑。追加一条人为的“Continue.”用户消息既无必要，还会向对话注入模型本不需要的文本；而从头重试则会丢弃已经付费的工作。
编号 QB-GKRWMM依据： Anthropic docs — Handling stop reasons: pause_turn报告此题的问题
11. 某一次助手轮次包含三个 tool_use 块，你的执行框架并发地执行了它们。这些结果必须如何返回？
- A.顺序与分组均可任意，因为 API 会按工具名称把结果与调用配对
- B.作为三条用户消息，每个工具一条，按工具完成的先后顺序
- C.作为一条用户消息，含三个 tool_result 块，各带对应的 tool_use_id✓ 答案
- D.作为一条助手消息，把三个结果拼接为文本
一次轮次中的每个 tool_use 块都需要恰好一个对应的 tool_result，且它们必须一起出现在紧跟助手轮次之后的那一条用户消息中。配对依据是 tool_use_id，而非工具名称或位置——当同一个工具在一轮中被调用多次时，这一点尤为关键。遗漏结果会产生“找到了 tool_use id 但其后没有紧跟 tool_result 块”的错误。
编号 QB-Y3KR2M依据： Anthropic docs — Messages API tool use: returning tool results报告此题的问题
12. 某团队发现，他们的智能体过去会一次请求多个工具，现在却几乎总是一次只请求一个。检查执行框架后，他们发现它把每个 tool_result 都放在各自独立的用户消息中发送。为什么这很重要？
- A.拆分结果会让模型认为并行调用未被兑现，从而不再并行调用✓ 答案
- B.每多一条用户消息就会重置对话历史，因此模型忘记了先前的调用
- C.工具结果仅在第一条用户消息中有效，后续的会被完全忽略
- D.独立的消息会被 API 拒绝，因此智能体悄然退化为每轮只调用一个工具
对话历史是模型判断环境行为方式的证据。当一次并行轮次的结果被拆分到多条用户消息中时，记录看起来就不再像“并行调用被一并应答”的轮次，模型便从这种形态中学到不再发起并行调用——这是一种静默的行为退化，而非硬性报错。把所有结果放在一条用户消息中返回可以保持并行模式。
编号 QB-FKDKFK依据： Anthropic docs — Messages API tool use: parallel tool use报告此题的问题
13. 在一次智能体运行中，对外部 API 的工具调用因限流错误而失败。执行框架应当回传什么？
- A.从循环中抛出异常，使运行中止以便稍后重启
- B.对该调用什么都不回传，只回传成功的工具的结果
- C.一个内容仅为单词“failed”的 tool_result
- D.is_error 为 true 且附指导性消息的 tool_result✓ 答案
工具失败应在契约内部予以标示，而不是破坏契约：回传 is_error 为 true 的 tool_result，让模型知道调用未成功。消息内容是模型据以恢复的推理材料，因此一条点明失败原因与补救方式的指导性消息能让它等待重试或改走他路，而单纯的“failed”则不提供任何可据以行动的信息。完全丢弃结果会导致某个 tool_use 块无人应答从而被拒绝，而让循环崩溃则会丢弃本可恢复的状态。
编号 QB-X38EVJ依据： Anthropic docs — Implement tool use: error handling with is_error报告此题的问题
14. 你想在同一条用户消息中返回两个工具结果，并额外附上一段供模型阅读的简短说明。这条消息必须如何排序？
- A.先放两个 tool_result 块，再放文本块✓ 答案
- B.在任何包含 tool_result 块的消息中都不允许出现文本
- C.交错排列：文本、结果、文本、结果
- D.先放文本块，再放两个 tool_result 块
在应答工具使用轮次的用户消息中，所有 tool_result 块必须排在最前，任何文本都要跟在其后；把文本放在 tool_result 之前会导致请求错误。这种排序使结果紧邻其所应答的助手轮次。还需注意一个相关约束：当助手轮次同时留有未解决的服务端工具调用时，回复中只能包含 tool_result 块——在那里添加文本会提前结束该轮次并被拒绝。
编号 QB-JKFKYP依据： Anthropic docs — Messages API tool use: tool_result block ordering报告此题的问题
15. 某平台团队正在两者之间做选择：一个围绕你自定义的工具驱动循环的 SDK tool-runner 辅助工具，与一个自带内置文件和 shell 工具的完整编码智能体 SDK。以下哪项陈述是准确的？
- A.tool runner 提供托管部署，而编码智能体 SDK 必须自托管
- B.两者都只提供 harness，需你自行托管，不同于另行提供的托管方案✓ 答案
- C.它们是同一个库的两个名字，因此选择纯粹是风格问题
- D.编码智能体 SDK 无法用你自定义的工具进行扩展
有两个相互独立的问题区分这些选项：谁提供 harness（循环加上下文管理），以及谁提供部署。tool runner 与编码智能体 SDK 都只提供 harness，区别在于其范围——tool runner 围绕你自定义的工具运行循环、不含内置工具，而编码智能体 SDK 自带读取、写入、编辑、shell 与搜索工具——但无论选哪个都由你自行托管和部署。只有托管式智能体方案才额外提供部署，由服务方运行智能体循环和按会话隔离的沙箱。
编号 QB-24AEDP依据： Anthropic docs — Agent development: building an agent, approaches compared报告此题的问题
16. 一项合规要求规定：智能体绝不能运行包含破坏性删除的 shell 命令，没有例外。团队写了一条措辞强硬的系统提示词规则，通常也确实有效。要让这一点具备确定性，正确做法是什么？
- A.调低模型的 effort 设置，使其采取更少的高风险动作
- B.在每条用户消息中都加入提醒模型遵守该规则的指令
- C.在模型之外用执行前钩子或权限规则拦截该调用✓ 答案
- D.在系统提示词的开头和结尾各重复一遍该规则，并使用全大写
系统提示词中的指令是一种很强的先验，但不是保证——它存在非零的失败率，因此无法满足“绝不、没有例外”这类要求。必须确定性成立的规则应放在 harness 中：工具执行前的钩子或权限规则在你的进程中运行，检查具体的工具输入，并在执行前短路该调用。改写、重复或用大写强调提示词只会改变概率，而不会带来保证。
编号 QB-HK49TN依据： Anthropic docs — Agent design: harness-level enforcement vs. prompting报告此题的问题
17. 一个协调者智能体把文档审查任务委派给子智能体，只说了“审查我们讨论过的那个模块的文档”。子智能体反问是哪个模块。为什么？
- A.子智能体的上下文被截断了，因为父代的历史太长
- B.子智能体的工具集中缺少能让它读取对话的那个工具
- C.子智能体从全新上下文开始，看不到父代的对话✓ 答案
- D.除非父代启用历史共享，否则子智能体无法读取对先前轮次的引用
上下文隔离是子智能体的本质属性：它开启一段全新的对话，加载自己的系统提示词和项目上下文，永远不会继承父代的轮次。这种隔离正是其收益所在——父代的上下文只增加一段简短摘要，而非整个子任务的完整记录——但它也带来一项义务：委派提示词必须自包含。诸如“我们讨论过的那个模块”这类代词和指代在另一侧无从解析。
编号 QB-Z3X38N依据： CCDV-F Exam Guide — Agent Patterns and Frameworks: subagent context isolation报告此题的问题
18. 下列哪项任务更适合委派给子智能体，而不是在主循环中直接完成？
- A.执行一次迁移，其中第二步依赖于第一步的确切输出
- B.复核主智能体已经给出的答案
- C.读取一个文件、在其中修改两行、然后运行该文件的测试
- D.分别调查四十个相互独立的模块是否引入已弃用的包✓ 答案
委派并非免费：每个子智能体都要重新建立自己的上下文、重新探索并汇报，协调者随后还要阅读该汇报——因此收益必须超过这些开销。真正独立的大规模扇出才是划算的场景，因为工作确实可并行，而父代的上下文只增加若干摘要。少数几次工具调用就能完成的工作、下一步依赖上一步的严格串行工作，以及对自身输出的验证，放在主循环中都更便宜也更可靠。
编号 QB-MK69BS依据： Anthropic docs — Agent design: delegation cost and fan-out报告此题的问题
19. 某智能体在第一条用户消息中收到了一条重要的格式规则。在长会话进行数小时后，自动压缩已对较早的历史做了摘要，智能体便不再遵守该规则。持久的修复方案是什么？
- A.把该规则移入每次请求都会重新注入的项目上下文✓ 答案
- B.禁用压缩，使会话永不丢失任何历史
- C.用更长、更强调的开场提示词重申该规则
- D.让智能体在开头复述一遍该规则以便“记住”
在同一会话内，上下文窗口不会在轮次之间重置——系统提示词、工具定义、历史记录、工具输入与工具输出都会累积——当接近上限时，较早的历史会被摘要压缩掉。因此，早期给出的指令恰恰是最容易在该摘要中丢失的，无论措辞多么强调。必须长期生效的规则应放入每次请求都会重新注入的项目上下文中，这样它们的存续就不依赖于对话记录。
编号 QB-44Z3RR依据： CCDV-F Exam Guide — Agent Patterns and Frameworks: context window management and compaction报告此题的问题
20. 某团队向其执行框架中新增了一个自定义搜索工具。它只读取索引、没有副作用，但框架仍然把它和其他所有工具一起串行运行。可能的原因是什么？
- A.并发由模型而非框架决定，因此任何配置都无法改变
- B.该工具未标记为只读，而自定义工具默认串行执行✓ 答案
- C.自定义工具永远无法并发运行，只有内置工具可以
- D.搜索工具因为访问索引，总是被视为会修改状态
只读操作（如读取、glob 匹配、grep 搜索）可以安全地并发运行，而修改状态的操作（如编辑、写入、执行 shell 命令）必须串行化。自定义工具对框架而言是不透明的，因此除非你声明其为只读，否则默认串行——这也正是宽泛的 shell 工具会强制串行的原因：框架无法在任意命令字符串中区分并行安全的 grep 与不安全的 push。
编号 QB-NQFF66依据： Anthropic docs — Agent design: parallel-safe tools and scheduling报告此题的问题
21. 某架构师需要选择第三方智能体框架。需求 A：控制流必须以带条件边的图显式写出，且长时间运行在崩溃后必须能从检查点恢复。需求 B：另一个服务必须保证模型输出符合已声明的类型，并在校验失败时自动重试。哪些框架特征与之匹配？
- A.两项需求都只能由模型驱动的轻量循环满足，因为一切由模型规划
- B.A：类型安全的校验框架。B：有状态的图框架
- C.A 用带检查点的有状态图框架，B 用类型安全的校验框架✓ 答案
- D.两项需求都无法由框架满足，都必须针对原始 API 手工编码
这些框架的区别在于定位与权衡，而非语法。面向图的一类把控制流写成由节点和条件边构成的显式状态机，并持久化检查点，这正是崩溃后可恢复能力的来源。类型安全的一类则以经过校验的结构化输出与依赖注入为核心，在响应不满足已声明模式时自动重试。模型驱动的轻量循环是相反的权衡：由模型来规划，因此控制流并未被写下，也就没有可供恢复的图。
编号 QB-68NMR6依据： CCDV-F Exam Guide — Agent Patterns and Frameworks: framework identities and tradeoffs报告此题的问题
22. 某智能体目前通过一个宽泛的 shell 工具完成所有操作。产品方希望在发送任何面向客户的邮件之前弹出确认对话框，并对每次发送记录审计日志。对工具面应做出的正确改动是什么？
- A.包装 shell 工具，使其在命令中提到 email 时返回 is_error
- B.把“发送邮件”提升为专用的类型化工具，便于框架拦截和审计✓ 答案
- C.彻底移除 shell 工具，使智能体无法执行任何未经审核的动作
- D.保留 shell 工具，并添加系统提示词指令，要求发送邮件前必须先询问
宽泛的 shell 工具带来了广度，却只给框架一个不透明的命令字符串——所有动作形态相同——因此无法可靠地对某个具体动作进行拦截、审计、渲染或并行化。把某个动作提升为带类型化参数的专用工具，就为框架提供了针对该动作的钩子。可逆性是判断哪些动作值得如此处理的标准：给客户发邮件难以撤销，因此是天然的候选；而对 shell 命令做“email”字符串匹配，恰恰是这种提升所要取代的脆弱检查。
编号 QB-MQ45Z4依据： Anthropic docs — Agent design: designing your tool surface报告此题的问题

本考试的其他主题

应用与 API 集成22 道免费练习题模型选择与优化23 道免费练习题提示工程、Claude Code 与评估23 道免费练习题安全、工具与 MCP23 道免费练习题

练习题依据官方 Claude 认证开发者基础级（CCDV-F）考试指南和 Anthropic 公开文档编写。这是一个独立的学习工具，与 Anthropic 无关联、未获其认可，也不授予任何认证。考试由 Pearson VUE 交付；当前的题量、考试时长、通过分数和费用以 Anthropic 官方 CCDV-F 考试指南公布的为准。官方认证页面 →

1. 某支付团队每晚运行一个对账作业：提取当天的账簿记录、进行规范化、与银行文件比对，然后邮件发送差异报告。这四个步骤始终相同、顺序固定，且审计要求每次运行都可复现。哪种架构最合适？

2. 下列哪项任务最能明确地证明应当构建智能体，而不是由代码编排的工作流？

3. 某开发者把应用中的每一次模型调用——包括一个纯粹的“总结这篇文章”接口——都包在一个检查 stop_reason 并执行工具的 while 循环里。对于总结接口来说，这样做的问题是什么？

4. 某营销团队分三个阶段生成活动文案：先起草大纲，再扩写为正文，最后做本地化。在第一阶段和第二阶段之间，用普通代码检查大纲是否包含必需的法律免责声明，若没有则退回第一阶段。这属于哪种模式？

5. 一个客服工单队列中混杂着密码重置、账单争议和 API 集成问题。每一类都由不同的提示词处理效果最好，而密码重置足够简单，可交给更便宜、更快的模型。哪种模式合适？

6. A 团队用一次模型调用回答用户问题，同时用第二次并发调用对同一输入做违规筛查。B 团队把同一份代码 diff 发给五次相同的评审调用，并汇总有多少次标记出漏洞。按顺序，这分别属于哪种并行化变体？

8. 在基于 Messages API 的自定义智能体循环中，模型返回的响应包含一个简短文本块和两个 tool_use 块。在返回工具结果之前，必须向消息列表中追加什么？

9. 某团队的智能体循环在助手文本包含“I have completed”时退出，或在十次迭代后退出，以先到者为准。为什么这被视为反模式？

10. 一个声明了服务端工具的智能体收到一个 stop_reason 为 pause_turn 的响应。正确的处理方式是什么？

11. 某一次助手轮次包含三个 tool_use 块，你的执行框架并发地执行了它们。这些结果必须如何返回？

12. 某团队发现，他们的智能体过去会一次请求多个工具，现在却几乎总是一次只请求一个。检查执行框架后，他们发现它把每个 tool_result 都放在各自独立的用户消息中发送。为什么这很重要？

13. 在一次智能体运行中，对外部 API 的工具调用因限流错误而失败。执行框架应当回传什么？

14. 你想在同一条用户消息中返回两个工具结果，并额外附上一段供模型阅读的简短说明。这条消息必须如何排序？

15. 某平台团队正在两者之间做选择：一个围绕你自定义的工具驱动循环的 SDK tool-runner 辅助工具，与一个自带内置文件和 shell 工具的完整编码智能体 SDK。以下哪项陈述是准确的？

16. 一项合规要求规定：智能体绝不能运行包含破坏性删除的 shell 命令，没有例外。团队写了一条措辞强硬的系统提示词规则，通常也确实有效。要让这一点具备确定性，正确做法是什么？

17. 一个协调者智能体把文档审查任务委派给子智能体，只说了“审查我们讨论过的那个模块的文档”。子智能体反问是哪个模块。为什么？

18. 下列哪项任务更适合委派给子智能体，而不是在主循环中直接完成？

19. 某智能体在第一条用户消息中收到了一条重要的格式规则。在长会话进行数小时后，自动压缩已对较早的历史做了摘要，智能体便不再遵守该规则。持久的修复方案是什么？

20. 某团队向其执行框架中新增了一个自定义搜索工具。它只读取索引、没有副作用，但框架仍然把它和其他所有工具一起串行运行。可能的原因是什么？

22. 某智能体目前通过一个宽泛的 shell 工具完成所有操作。产品方希望在发送任何面向客户的邮件之前弹出确认对话框，并对每次发送记录审计日志。对工具面应做出的正确改动是什么？

本考试的其他主题