当前位置：首页 > news >正文

ReAct框架：从算法概念到工程契约的面试实战解析

news 2026/8/14 9:45:07

1. 从“算法”到“契约”：ReAct面试追问的本质转换

最近在帮团队面试候选人，特别是涉及大模型应用和智能体方向的岗位时，我发现一个高频出现的“八股文”考点：ReAct。很多候选人一听到这个词，立刻条件反射般地背诵：“ReAct是Reasoning and Acting的缩写，是一种结合推理与行动的框架，通过‘思考-行动-观察’的循环来解决复杂问题……” 听起来很标准，对吧？但当我追问下去：“那么，在你们实际的项目里，ReAct具体是如何落地的？Prompt里怎么写思考步骤？工具调用失败怎么兜底？和Chain-of-Thought（CoT）在工程实现上到底有什么区别？” 场面往往就变得有些微妙了。

这正是我想和你探讨的核心：ReAct，在面试官眼中，早已不是一个需要背诵定义的“算法”，而是一份检验你工程化思维的“契约”。这份契约，连接着抽象的问题域（用户想要什么）和具体的实现域（代码怎么写），面试官的所有追问，本质上都是在考察你对这份契约的理解深度和履约能力。如果你只停留在概念复述，相当于只记住了合同封面，却对里面的条款细节、履约标准、违约处理一无所知，这显然无法通过一场严肃的技术面试。

为什么是“契约”？想象一下，你要开发一个能帮用户订机票、订酒店、查天气的旅行助手智能体。用户说：“下周末我想去杭州玩，预算5000块。” 这是一个典型的需要多步工具调用和条件判断的复杂任务。ReAct框架就像你和这个任务之间签订的一份开发契约：

契约目标（Objective）：必须正确、可靠地完成用户指定的复杂任务。
核心条款（Core Clauses）：
1. Reasoning（思考）：你必须先拆解任务，明确步骤，不能蛮干。
2. Acting（行动）：你必须调用被授权的、定义好的工具（如搜索API、计算器、数据库查询）来执行具体操作。
3. Observation（观察）：你必须检查工具返回的结果，判断是否有效、是否足够进行下一步。
履约流程（Procedure）：遵循“思考 → 行动 → 观察 → 再思考…”的循环，直到任务完成或明确失败。
违约责任（Penalty）：如果陷入死循环、调用错误工具、或给出错误答案，则视为契约履行失败。

面试官问你ReAct，不是想听你朗读这份契约的标题，而是想看你如何设计、签署并执行它。他会从“问题域”出发，一路追问到“实现域”，这个完整的映射过程，才是面试的核心战场。

2. 问题域拆解：面试官到底在问什么？

当面试官抛出“谈谈你对ReAct的理解”这个问题时，资深面试官的大脑里激活的绝不是一个简单的概念检索。他实际上是在启动一个多层次的评估雷达，扫描的是你如何将一个模糊的、高层次的业务需求，精准地翻译成可被技术框架处理的明确任务。我们可以把这个过程拆解为三个递进的层面。

2.1 第一层：概念辨析与定位能力

这是最基础的关卡，但也是淘汰率不低的一关。面试官在此层主要验证你是否具备清晰的技术图谱认知，能否将ReAct准确地放置在整个大模型技术生态中。

追问示例1：“ReAct和Chain-of-Thought（CoT）以及Plan-and-Execute（P&E）框架的主要区别是什么？分别在什么场景下优先选用？”
- 面试官意图：考察你对不同推理范式的本质理解。他期待的不是背定义，而是一个基于“任务复杂度”和“工具依赖度”的决策矩阵。
- 高分回答思路：
  - CoT：核心是“纯推理”。适用于无需外部交互、仅靠模型内部知识链式思考就能解决的推理密集型问题，如数学解题、逻辑谜题。它的输出是一段连续的文本推理过程。你可以说：“当任务是一个封闭域的、定义良好的推理问题时，比如‘如果A在B左边，C在A右边，那么B和C的相对位置是什么？’，CoT是最高效的，因为它不涉及外部调用开销。”
  - ReAct：核心是“推理+行动”。适用于必须与外部世界（工具、API、数据库）交互才能完成的工具调用密集型问题，如信息检索、数据操作、设备控制。它的输出是交织的“Thought-Action-Observation”序列。你可以补充：“比如用户问‘帮我查一下北京今天天气，如果下雨就推荐室内活动’，这必须调用天气API（行动），根据返回结果（观察）再决定下一步推理（思考），这就是ReAct的典型场景。”
  - P&E：核心是“先规划，后执行”。适用于步骤相对固定、可预先完全确定的流程化任务。它先生成一个完整的步骤列表（Plan），然后逐一执行（Execute），缺乏ReAct中间的动态观察和调整。你可以对比：“P&E像按照菜谱做菜，步骤已知；ReAct像在陌生丛林探险，需要边走边看地图（观察）并调整路线（思考）。”
- 避坑点：切忌说“ReAct是CoT的升级版”或“P&E比ReAct更好”。要强调场景适配性。
追问示例2：“在ReAct循环中，‘Thought’步骤是必须的吗？能不能直接‘Action’？”
- 面试官意图：考察你是否理解ReAct中“Reasoning”的核心价值——减少幻觉和盲目操作。
- 高分回答思路：必须强调“Thought”的关键性。“直接‘Action’就退化成了简单的函数调用链，失去了对大语言模型核心优势——推理能力——的利用。‘Thought’步骤的作用是：1)明确意图：将上一步的观察转化为下一步行动的具体目标；2)工具选择：从工具集中选出最合适的一个；3)参数构造：根据当前上下文，生成调用工具所需的准确参数。缺少思考，模型很容易基于错误的理解调用错误工具，或生成无效参数。” 可以举一个反例：“用户说‘我饿了’，如果直接行动，模型可能随机调用一个‘食谱查询’工具。但经过思考‘用户说饿了，可能是想找餐馆，我需要知道他的位置和口味偏好’，从而主动发起询问，这才是合理的路径。”

2.2 第二层：场景抽象与任务分解能力

通过第一层后，面试官会假设你懂概念，进而考察你能否将真实的、模糊的业务需求，抽象成一个适合用ReAct解决的任务范式。这是连接业务和技术的桥梁。

追问示例：“现在要设计一个智能客服系统，处理‘我的订单物流卡住了，怎么办？’这类问题。如何用ReAct的思路来设计它的工作流？”
- 面试官意图：考察你的系统思维和分解能力。他期待你展示出从用户一句话到一系列原子操作的过程。
- 高分回答思路：不要直接跳进技术细节。先进行问题域分析。
  1. 目标拆解：用户的核心目标是获取物流卡顿的原因和解决方案。这需要多种信息：订单号、物流详情、卡顿环节、可选操作（催单、联系物流、退款等）。
  2. 工具集定义：要完成上述目标，我们需要哪些“工具”？这定义了Acting的边界。例如：get_order_id_from_session（从会话获取订单）、query_logistics_api(order_id)（查询物流API）、identify_problem_node(tracking_info)（识别问题节点）、get_resolution_options(problem_node)（获取解决方案）、initiate_customer_service_chat（转人工）。
  3. ReAct循环设计：描述一个理想的处理序列。
    - Thought 1：用户反馈物流问题。我需要先确定具体是哪个订单。
    - Action 1：调用get_order_id_from_session。
    - Observation 1：获得订单号ORD123456。
    - Thought 2：现在需要用订单号查询最新的物流详情。
    - Action 2：调用query_logistics_api(ORD123456)。
    - Observation 2：返回信息显示包裹在“杭州转运中心”停留超过48小时。
    - Thought 3：识别到“转运中心滞留”是常见卡顿节点。需要查找可能的原因和用户可执行的操作。
    - Action 3：调用get_resolution_options(“hub_delay”)。
    - Observation 3：返回选项：1. 自动催单；2. 提供物流客服电话；3. 说明可能原因（节假日、安检等）。
    - Thought 4：将信息和选项组织成友好回复，并询问用户选择。
    - （最终响应）：告知用户物流状态，提供原因解释和可操作选项。
- 加分项：指出其中的不确定性处理，比如“如果get_order_id_from_session工具返回空，思考步骤应转为‘主动询问用户订单号’”。

2.3 第三层：约束识别与边界划定能力

这是区分普通开发者和优秀架构师的关键。任何工程契约都有其生效范围和限制条件，ReAct也不例外。面试官会考察你是否能清醒地认识到它的能力边界和潜在风险。

追问示例1：“ReAct框架在处理任务时，可能会陷入无限循环或执行无用操作，如何从工程上规避这些问题？”
- 面试官意图：考察你对ReAct局限性的认知以及你的工程兜底能力。
- 高分回答思路：承认这是ReAct实践中的主要挑战之一，并提出系统化的解决方案。
  1. 设置最大迭代次数：这是最基本的防护网。在ReAct循环外层设置一个计数器（如最多10轮），超时则强制退出，并返回“任务过于复杂，建议简化问题或转人工”的提示。
  2. 定义清晰的终止状态：在Prompt中明确告诉模型哪些情况代表任务成功完成（如“当给出了最终答案”、“当提供了用户请求的完整信息”），哪些情况代表需要停止（如“当工具返回错误且无法重试”、“当用户明确表示取消”）。
  3. 工具调用结果验证：在Observation后加入一个隐性的“有效性判断”步骤。例如，调用搜索工具后，如果返回“未找到相关信息”，应将其视为一个有效观察，并引导模型思考换关键词或承认信息缺失，而不是盲目重试。
  4. 状态去重与剪枝：维护一个历史状态记录（如已尝试的(Thought, Action)对）。当模型产生与历史高度相似的思考时，可以介入提示或直接跳过，防止在局部死循环。
  5. 引入监督器（Supervisor）或验证器（Verifier）：这是一个更高级的模式。让一个更轻量或更专注的模型/规则系统，对主模型的每一步输出（特别是Action）进行合理性检查，再决定是否执行。
追问示例2：“对于工具调用（Action）的失败，ReAct框架应该如何设计重试和降级机制？”
- 面试官意图：考察你的分布式系统设计思维和鲁棒性设计能力。工具调用本质上是远程服务调用，必然涉及失败。
- 高分回答思路：将工具调用视为微服务调用，套用成熟的模式。
  1. 重试策略：对于网络超时、瞬时错误等，采用指数退避策略进行有限次重试（如最多3次）。关键点：重试时，思考（Thought）步骤可能需要调整参数，例如搜索工具因关键词太模糊失败，重试前应思考更具体的关键词。
  2. 降级方案：
    - 工具降级：如果A工具（如精确数据库查询）失败，能否用B工具（如模糊搜索引擎）替代？这需要在工具定义和模型Prompt中体现这种备选关系。
    - 结果降级：如果无法获取精确数据，能否基于已有信息和模型知识，给出一个带有明确不确定性声明的估算或建议？例如，“无法查询到实时库存，但根据一般情况，这个商品通常有货。”
  3. 优雅失败与用户反馈：当所有重试和降级都失败后，必须向用户清晰、友好地说明情况，并可能提供替代路径。例如，“目前无法获取您的实时物流信息，系统可能正在维护。您可以通过订单页面的‘联系客服’直接咨询，或稍后再试。”

3. 实现域攻坚：从Prompt设计到系统集成

理解了问题域的种种考问，我们终于要进入实战环节——如何将这份ReAct“契约”用代码实现。面试官在这里的追问会极其具体和深入，直指工程落地的核心细节。这部分的回答质量，直接决定了你是“纸上谈兵”还是“真刀真枪”。

3.1 Prompt工程：如何撰写一份清晰的“契约条款”

ReAct的灵魂，很大程度上封装在给大模型的Prompt里。这份Prompt就是契约的详细条款，规定了模型的思考格式、工具描述和行为规范。写不好Prompt，ReAct就无法可靠工作。

核心结构剖析：一个工业级的ReAct Prompt通常包含以下几个部分：
1. 系统角色与任务定义：明确告诉模型它现在是谁，要做什么。“你是一个擅长使用工具解决问题的AI助手。你的任务是通过思考、行动、观察的循环，逐步解决用户的问题。”
2. 输出格式强制规定：这是确保机器可解析的关键。必须使用严格的、无歧义的分隔符。
```
请严格按照以下格式响应： Thought: [你的思考过程，分析当前情况，决定下一步做什么] Action: [要调用的工具名称，必须是以下工具之一：{工具列表}] Action Input: [调用该工具所需的输入参数，通常是一个JSON字符串] Observation: [工具执行后返回的结果] ...（这个循环可以重复多次） Final Answer: [当任务完成时，基于所有观察给出最终答案]
```
3. 工具手册：清晰定义每个工具的“名称”、“描述”、“输入参数格式”和“输出示例”。描述要具体，说明工具能做什么、不能做什么。例如：
  - search_web: “使用此工具在互联网上搜索最新信息。输入应为搜索关键词字符串。输出为相关的网页摘要列表。”
  - calculator: “使用此工具进行数学计算。输入为一个数学表达式字符串，如'(12+5)*3'。输出为计算结果数字。”
  - get_current_time: “使用此工具获取当前日期和时间。输入为空字符串或null。输出为当前时间的字符串。”
4. 约束与规则：明确告诉模型什么不能做。例如：“你只能使用上面列出的工具。如果用户请求需要工具但列表中没有，请说明你无法做到。”、“在得到最终答案前，不要提前说‘根据以上信息’之类的话。”、“如果工具返回错误或未找到信息，请将其视为观察，并思考下一步。”
5. 示例（Few-Shot）：提供1-2个完整的、从问题到Final Answer的ReAct循环示例。这是让模型快速掌握格式和逻辑的最有效方式。
面试追问点：“如何设计工具的描述，才能最大程度减少模型调用错误工具或生成错误参数的情况？”
- 实战经验：
  - 名称直观：工具名最好能望文生义，如search_news比tool_alpha好得多。
  - 描述具体化、场景化：不要只说“查询数据”，要说“根据用户提供的订单号，查询该订单的当前状态、物流轨迹和预计送达时间。订单号通常为10-12位数字字符串。”
  - 输入输出示例化：给出明确的、可复制的例子。Action Input: {"order_id": "ORD20231001123"}比Action Input: 订单号要好得多。
  - 说明边界条件：“此工具仅能查询最近90天内的订单。”、“如果订单号不存在，将返回{'error': 'Order not found'}。”

3.2 循环控制与状态管理：契约的履约监督

有了好的Prompt，模型就会按格式输出。但如何驱动这个循环，并管理其中的状态，是后端工程的核心。

基础循环实现：一个最简单的ReAct执行器伪代码如下：

def react_loop(initial_question, tools, max_turns=10): history = [] # 存储完整的 Thought, Action, Observation 序列 current_prompt = build_prompt(initial_question, tools, history) for turn in range(max_turns): # 1. 调用LLM，获取响应 llm_response = call_llm(current_prompt) # 2. 解析响应，提取 Thought, Action 等部分 parsed = parse_llm_response(llm_response) # 需要健壮的解析器 # 3. 检查是否为最终答案 if parsed.get('final_answer'): return parsed['final_answer'], history # 4. 执行 Action tool_name = parsed['action'] tool_input = parsed['action_input'] if tool_name not in tools: observation = f"Error: Tool '{tool_name}' not found." else: observation = tools[tool_name].execute(tool_input) # 5. 将本次循环的 (Thought, Action, Observation) 加入历史 history.append({ 'thought': parsed['thought'], 'action': tool_name, 'action_input': tool_input, 'observation': observation }) # 6. 构建下一轮Prompt（包含完整历史） current_prompt = build_prompt(initial_question, tools, history) # 循环耗尽，返回超时 return "Task could not be completed within the maximum turns.", history

面试追问点：“parse_llm_response这个解析函数在实现时要注意哪些坑？”
- 深度解析：这是故障高发区。模型输出并不总是严格遵守格式。
  1. 正则表达式 vs. 结构化输出：早期多用正则（如r'Thought:\s*(.*?)\nAction:'）匹配，但脆弱。现在更优解是要求LLM使用结构化输出（如JSON模式）。在Prompt中要求模型直接输出一个JSON对象，包含thought,action,action_input等字段，可大幅提升解析可靠性。
  2. 容错处理：必须考虑模型输出格式错误的情况：字段缺失、分隔符错误、在Thought里包含了“Action:”这样的关键词。解析函数应有多层fallback逻辑，比如先尝试JSON解析，失败再尝试正则，再失败则尝试寻找关键词行，最后可触发一个“修复Prompt”让模型重新生成格式正确的输出。
  3. 上下文截断：随着循环进行，history会越来越长，可能超出模型的上下文窗口。需要在build_prompt函数中实现智能截断策略：优先保留最近的几次循环和最重要的早期信息（如初始问题），或对历史进行摘要。

3.3 工具层的工程化设计

工具（Action）是ReAct与真实世界交互的手脚。工具层的设计直接决定了智能体的能力范围和可靠性。

工具抽象与注册：设计一个统一的工具接口（Tool抽象类），所有具体工具（如搜索、计算、查询）都实现这个接口。有一个中央注册表（ToolRegistry）来管理所有可用工具。这样，ReAct执行器只需和注册表交互，便于扩展和维护。

class Tool: name: str description: str parameters_schema: dict # JSON Schema，用于描述输入格式 def execute(self, input_data: dict) -> str: ... class CalculatorTool(Tool): name = "calculator" description = "Performs arithmetic calculations." parameters_schema = {"type": "object", "properties": {"expression": {"type": "string"}}} def execute(self, input_data): try: result = eval(input_data["expression"]) # 注意：生产环境需用安全计算库如 `ast.literal_eval` return str(result) except Exception as e: return f"Calculation error: {e}" # 注册 registry.register(CalculatorTool())

面试追问点：“工具执行（tool.execute）可能涉及网络调用、数据库查询等IO操作，如何保证整个ReAct循环的效率和稳定性？”
- 工程化考量：
  1. 超时控制：每个工具调用必须设置独立的超时时间（如5秒），防止一个缓慢的工具拖垮整个会话。
  2. 异步执行：ReAct循环本质上是顺序的（需要上一步的Observation才能进行下一步Thought），但工具执行本身可以放在异步任务中，避免阻塞主循环线程，特别是在需要并行调用多个子工具时。
  3. 错误隔离与熔断：如果某个工具连续失败多次，应触发熔断机制，暂时将其从可用工具列表中移除，并返回一个预定义的错误观察（如“该服务暂时不可用”），防止ReAct循环持续尝试并失败。
  4. 结果缓存：对于幂等的、结果变化不频繁的工具调用（如“查询某产品的规格”），可以引入缓存。将(tool_name, action_input)作为键，缓存观察结果，能极大提升响应速度并降低下游服务压力。

4. 超越基础：面试中的高阶追问与实战案例

当你能流畅回答前述所有问题，面试官可能会露出欣赏的微笑，然后抛出一些更刁钻、更接近真实业务复杂性的问题。这部分考察的是你的洞察力、批判性思维和解决模糊问题的能力。

4.1 追问：ReAct的“思考”真的在思考吗？如何评估其质量？

这是一个触及本质的哲学兼工程问题。面试官想看你是否深入思考过LLM在ReAct中的角色局限。

高分回答框架：
1. 承认其局限性：“严格来说，LLM的‘Thought’并非人类意义上的思考，而是一种基于概率的、对下一步最可能文本的生成。它没有真正的因果推理或规划能力，只是模仿了思考的‘形式’。”
2. 强调其工程价值：“但在工程上，这种‘形式化思考’极具价值。它强制模型将内部推理过程‘外化’，这带来了两个关键好处：一是可解释性，我们可以追溯错误决策的思维链；二是可控性，我们可以通过Prompt引导、格式化输出和事后分析，来约束和优化这个推理过程，使其更可靠。”
3. 提出评估方法：
  - 过程评估：检查Thought序列的逻辑连贯性。每一步Thought是否合理利用了上一步的Observation？工具选择是否恰当？参数生成是否准确？
  - 结果评估：最终答案是否正确？这是终极标准。
  - 效率评估：完成任务所需的循环次数是否合理？是否存在冗余或循环？
  - 人工评估（黄金标准）：对于关键任务，抽样进行人工评审，标注Thought的质量（如：相关/不相关，逻辑正确/错误）。
4. 介绍改进方向：“为了提高‘思考’质量，我们可以：a) 提供更优质的Few-Shot示例；b) 使用更强的基座模型；c) 采用Self-Reflection技术，让模型在输出Final Answer前，对自己的整个思考过程进行一次批判性回顾和修正。”

4.2 实战案例剖析：设计一个“多模态ReAct”智能体

假设面试官问：“如果想让智能体不仅能处理文本，还能‘看’图片（例如，用户上传一张商品图问‘这是哪年的款式？’），ReAct框架应该如何扩展？”

回答思路：这考察的是你对ReAct框架扩展性的理解。
1. 问题分析：核心变化是输入从纯文本变成了“文本+图像”。模型需要理解图像内容作为推理依据。
2. 架构扩展：
  - 前端：需要支持多模态输入（文本+图像上传）。
  - 模型层：需要从纯文本LLM切换到多模态大模型（MLLM），如GPT-4V、Claude-3 Opus等，它们能同时理解图像和文本。
  - Prompt设计：Prompt中需要指示模型“你将看到一张图片和一段文字”。在Few-Shot示例中，也要包含多模态的示例。Thought步骤现在需要基于图像内容进行分析，例如：“用户上传了一张鞋子的图片。从图片看，这是一款复古跑鞋，有特定的logo和线条设计。我需要识别出具体的品牌和型号。”
  - 工具层：可以引入专门的视觉工具，例如：extract_text_from_image（OCR工具）、describe_image（图像描述工具）、search_product_by_image（以图搜商品工具）。模型在Thought步骤后，可以选择调用这些视觉工具。
3. 工作流示例：
  - 用户输入：（图片+“这是哪年的款式？”）
  - Thought 1：用户提供了一张产品图片并询问年份。我需要先识别出这是什么产品。
  - Action 1：describe_image(输入：上传的图片)
  - Observation 1：“这是一双白色的耐克Air Max 90运动鞋，红黑配色，鞋底有可见的气垫。”
  - Thought 2：现在我知道这是耐克Air Max 90。我需要查找这款特定配色款式的发布年份。
  - Action 2：search_web(输入：“Nike Air Max 90 white red black release year”)
  - Observation 2：“根据多个球鞋资料站信息，这款‘Nike Air Max 90 ‘Infrared’’ 配色最初于1990年发布，并在2020年有复刻版本。”
  - Thought 3：用户图片中的鞋子看起来很新，可能是复刻版。我需要结合图片细节判断。
  - Action 3：search_web(输入：“how to distinguish 1990 original vs 2020 retro Nike Air Max 90 Infrared”)
  - Observation 3：“主要区别在于鞋舌标签、鞋盒和材质。2020复刻版的鞋舌标签有QR码…”
  - （后续可能调用更多工具或给出最终答案）
4. 挑战与考量：指出扩展后的复杂性：多模态模型成本更高、响应更慢；图像描述可能不准确；需要更精细的工具设计和错误处理。

4.3 追问：当工具不够用时，如何让ReAct智能体学会“求助”或“创造”？

这是考察智能体自主性的边界。现实世界中，工具集不可能覆盖所有情况。

回答思路：展示你对智能体行为边界和用户体验的综合考虑。
1. 明确核心原则：ReAct智能体的首要原则是可靠性和安全性。它不能执行未定义、未授权的操作。因此，“创造”新工具通常不被允许，但“求助”是必须设计的能力。
2. 设计“求助”机制：
  - 内部求助（降级）：在Prompt中明确，如果现有工具无法完成任务，模型应在Thought中分析原因，并尝试将任务分解或转化为一个能用现有工具近似解决的问题。例如，没有“翻译合同条款”的工具，但可以用“搜索该条款的常见解释”工具来替代。
  - 外部求助（转人工）：这是关键兜底策略。设计一个特殊的escalate_to_human工具。当模型经过若干轮循环后，判断自己无法解决（如工具反复失败、信息不足、问题超出范围），就调用此工具。调用时，Action Input应包含当前的问题、已尝试的步骤和遇到的障碍，以便人类接手时能快速理解上下文。
3. 模拟“创造”的有限形式：在某些高度可控的场景下，可以允许一种有限的“创造”——动态工具组合。即模型可以将几个基础工具组合成一个“虚拟”的新步骤。例如，没有“计算平均房价”的工具，但模型可以思考：“我需要先search_web获取某城市各区房价列表，然后extract_data提取数字，最后calculator计算平均值。” 这需要模型对工具的组合逻辑有很强的理解，并在Prompt中给予明确引导和示例。
4. 强调安全边界：无论如何设计，都必须有硬性约束：模型绝不能生成或执行任意代码、不能发起未授权的网络请求、不能访问未明确开放的数据源。所有“创造”必须在沙箱和预先审核过的工具组合范围内进行。

面试中对ReAct的考察，就像一场针对“智能体系统工程”能力的深度答辩。它从最基础的概念契约开始，逐步深入到场景分析、架构设计、异常处理乃至哲学思考。记住，面试官手中的每一个问题，都是这张“契约”的不同条款。你的任务就是证明，你不仅读过这份契约，更有能力在复杂的现实环境中，作为一名可靠的工程师，去设计、实现并运维它。当你能够将“问题域”的用户需求，通过“ReAct契约”清晰无误地映射到“实现域”的每一行代码和每一次工具调用时，你就已经通过了这场关于智能体时代核心开发思维的严峻考验。

查看全文

http://www.jsqmd.com/news/1390808/