deepagents 航空客服策略文档policy.md全解析tau2 Airline 评测中的规则约束与执行细节【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本文以 libs/evals/tests/evals/tau2_airline/data/policy.md 为绝对主线逐节拆解这份航空客服 Agent 业务策略。它定义了 Agent 在 book订票、modify改签、cancel取消与 refunds/compensation退款与补偿四类场景下的全部行为边界同时结合同目录下的 domain.py、evaluation.py、test_tau2_airline.py 等源码说明该策略如何被装载进 deepagents 系统提示词、被 14 个 LangChain 工具调用链执行、并被 DB 状态比对 沟通信息检查双维度打分。读完本文你将完整掌握这份策略文档的规则矩阵、其与底层工具实现的对应关系以及 tau2 评测的判定机制。一、策略文档在评测体系中的定位在 deepagents 仓库中这份 policy.md 并非普通的产品说明而是 libs/evals/tests/evals/tau2_airline 评测模块的规则引擎。它由 domain.py 中的load_policy()函数直接读取并原样注入 Agent 系统提示词def load_policy() - str: Load the airline customer service policy. with (_DATA_DIR / policy.md).open() as fp: return fp.read()真正的注入发生在 test_tau2_airline.py 的测试夹具中AGENT_SYSTEM_PROMPT模板把整个策略放进policy.../policy标签内通过create_deep_agent构建带 checkpointer 的 deepagents 图AGENT_SYSTEM_PROMPT \ You are a customer service agent that helps the user according to the policy provided below. Use the available tools to look up information, verify customer identity, and take actions. Always follow the policy. Be helpful, concise, and accurate. policy {domain_policy} /policy\ agent create_deep_agent( modelmodel, toolstools, system_promptAGENT_SYSTEM_PROMPT.format(domain_policypolicy), checkpointerMemorySaver(), )该模块源自 Sierra Research 的 τ-bench / τ²-bench / τ³-benchMIT License见目录内 LICENSE是验证Agent 能否在复杂业务规则约束下合规工作的标准场景。策略文档设置了固定的模拟时间2024-05-15 15:00:00 EST这与 domain.py 中_CURRENT_DATETIME 2024-05-15T15:00:00保持一致保证24 小时取消窗口已起飞航班等时间敏感规则可判定。二、全局行为准则所有动作的第一道门槛policy.md 开头部分是适用于全部场景的通用规则也是评测中最容易被扣分的隐性红线准则原文要点实现印证先确认再执行任何会更新预订数据库的动作订票、改航班、改行李、改舱位、改乘客信息必须先列明动作细节并取得用户明确的 yes对应book_reservation、update_reservation_flights等工具的入参均为用户确认后一次性提交的设计不越界输出不得提供用户或工具之外的信息、知识、流程不得给出主观建议对应 user_sim.py 中模拟用户不编造场景外信息的对称约束一次只做一件事一次只能调用一个工具调用工具时不得同时回复用户对应run_multi_turn单轮单次run_agent的驱动方式拒绝违规请求对违反本策略的请求必须拒绝大量测试任务的nl_assertions就是检查Agent 是否拒绝转人工仅当请求超出自身动作范围时才转人工先调用transfer_to_human_agents再发送固定话术YOU ARE BEING TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON.domain.py 中transfer_to_human_agents(summary)工具以及 user_sim.py 中###TRANSFER###终止令牌与之呼应从源码结构看transfer_to_human_agents是 14 个工具中唯一一个结束会话性质的出口用户模拟器识别到转人工时输出###TRANSFER###令牌双方通过这一协议完成场景收束。三、领域基础知识User、Flight、Reservation 三个数据模型策略文档紧接着定义了评测世界的三个核心实体这些实体在 domain.py 中被建模为 Pydantic 模型并最终由db.json见 libs/evals/tests/evals/tau2_airline/data/db.json装载User用户每个用户包含user id、email、地址、出生日期、支付方式、会员等级、预订号列表。两类枚举值是策略计算的关键支付方式三种credit card信用卡、gift card礼品卡、travel certificate旅行凭证。会员等级三种regular、silver、gold——直接决定免费托运行李额度见下文行李配额矩阵。对应源码User模型payment_methods: dict[str, PaymentMethod]PaymentMethod 是 CreditCard | GiftCard | Certificate 的联合类型membership: MembershipLevel。Flight航班航班属性航班号、出发地、目的地、计划起飞/到达时间均为当地时间。同一航班在多个日期各有状态available未起飞可订列出各舱位余座与价格delayed / on time未起飞但不可预订flying已起飞未落地不可预订另有 landed、cancelled 状态见 domain.py 的FlightDateStatus联合类型。舱位三种basic economy基础经济舱独立于 economy、economy、business。余座与价格按舱位分别列出。源码中的_search_direct_flights正是按此实现筛选逻辑if flight.dates[date].status ! available: continue即只有 available 状态才进入可订结果集。Reservation预订每个预订包含reservation id、user id、trip type行程类型、flights、passengers、payment methods、created time创建时间、baggages、travel insurance information旅行保险信息。行程类型两种one way单程、round trip往返。对应源码Reservation模型字段flight_type、cabin、flights、passengers、payment_history、created_at、total_baggages、nonfree_baggages、insurance、status。四、Book flight订票策略最密集的业务流订票流程是策略文档中规则最密集的部分Agent 必须按顺序采集信息并严格遵守约束。policy.md 的规定与 domain.py 中book_reservation工具的输入校验一一对应。信息采集顺序首先必须取得user id然后询问trip type、origin出发地、destination目的地依次确认舱位、乘客、支付方式、托运行李、旅行保险。对应book_reservation的完整入参 schemaBookReservationInputuser_id, origin, destination, flight_type, cabin, flights, passengers, payment_methods, total_baggages, nonfree_baggages, insurance。舱位约束同一预订内所有航班舱位必须一致源码中Reservation.cabin是单一字段天然保证这一点。乘客约束每个预订最多 5 名乘客需收集每位乘客的 first name、last name、date of birth对应Passenger模型的 first_name/last_name/dob所有乘客必须乘坐相同的航班、相同的舱位源码按len(parsed_passengers)统一计算座位与价格。支付约束每个预订最多 1 张旅行凭证 1 张信用卡 3 张礼品卡旅行凭证的剩余金额不可退款源码中证书扣款后直接user.payment_methods.pop(pm.payment_id)移除不会找零出于安全考虑所有支付方式必须已存在于用户档案中源码逐一校验pm.payment_id not in user.payment_methods即报错。免费托运行李配额矩阵核心表格务必完整继承配额由订票用户的会员等级×每位乘客的舱位共同决定订票用户会员等级basic economy 乘客economy 乘客business 乘客regular0 件1 件2 件silver1 件2 件3 件gold2 件3 件4 件超出免费额度的每件行李 50 美元源码total_price 50 * nonfree_baggages与此一致不得添加用户不需要的托运行李——这是典型过度服务陷阱评测中会通过nl_assertions检查。旅行保险Agent必须主动询问用户是否购买旅行保险每人 30 美元购买后若因健康或天气原因取消航班可全额退款源码total_price 30 * len(parsed_passengers)按乘客数计费。五、Modify flight改签分段规则与API 不检查陷阱改签场景首先要求取得user id 与 reservation id用户必须提供 user id若用户不知道 reservation idAgent 应使用工具协助定位get_user_details返回用户的预订列表。改航班Change flightsbasic economy 航班不可改签其他预订可改签但不得改变 origin、destination、trip type部分航段可以保留但保留航段的价格不会按当前价格更新源码update_reservation_flights中existing逻辑保留航段沿用existing.price关键警告API 不会替 Agent 校验这些规则so the agent must make sure the rules apply before calling the API——即策略合规是 Agent 自身的责任这正是评测的核心考察点。对应工具为update_reservation_flights(reservation_id, cabin, flights, payment_id)其参数描述明确要求All flight segments must be included (even unchanged ones)改签时必须提交全部航段含未改动的。改舱位Change cabin若预订中任一航班已起飞则不能改舱位其他情况含 basic economy 预订可在不改变航班的前提下改舱位同一预订内所有航段舱位必须一致不能只改某一个航段改后价格更高 → 用户需补差价改后价格更低 → 用户应获得差额退款。改行李与保险Change baggage and insurance行李只能增加不能减少预订创建后不能再添加保险。改乘客Change passengers可以修改乘客信息但不能修改乘客数量策略明确强调Even a human agent cannot modify the number of passengers——源码update_reservation_passengers中if len(parsed) ! len(reservation.passengers): raise ToolException(Number of passengers does not match)硬性校验了这一点。支付若航班被更改用户需提供一张礼品卡或信用卡作为支付/退款方式且必须已在用户档案中源码_payment_for_update同时拒绝证书Certificate cannot be used to update reservation。六、Cancel flight取消四种合法理由与转人工边界取消场景同样要求 user id reservation id未知则用工具定位且必须取得取消原因change of plan、airline cancelled flight、other。硬性边界若航班任何部分已经起飞Agent 无法处理必须转人工。四种可取消条件满足任一即可预订发生在最近 24 小时内航班被航空公司取消是business 舱位的预订用户购买了旅行保险且取消原因在保险覆盖范围内健康或天气原因。同样有API 不检查警告cancel_reservation工具本身不做策略判断Agent 必须在调用前自行核对规则。退款退款将在5 至 7 个工作日内原路退回源码cancel_reservation向payment_history追加等额负值退款记录即按原支付方式冲销。七、Refunds and Compensation退款与补偿谨慎授予的证书逻辑补偿场景是防滥用设计的典型策略强调不主动提出补偿、补偿前必须核实事实不主动提供补偿除非用户明确要求不向regular 会员 无保险 乘坐基础经济舱的用户补偿补偿前总是先确认事实仅当用户是 silver/gold 会员或购买了保险或乘坐 business 舱位时才可补偿。两种允许的补偿均为 certificate 证书形式对应send_certificate(user_id, amount)工具场景前提金额预订中航班被取消且用户投诉核实事实后$100 × 乘客数预订中航班延误且用户投诉并要求改签/取消核实事实并完成改签/取消后$50 × 乘客数除上述理由外不得因任何其他理由提供补偿。八、从策略到评测DB COMMUNICATE 双重打分机制策略合规与否如何被机器判定evaluation.py 实现了 τ-bench 风格的评估管线evaluate_task的最终奖励为reward db_score * communicate_scoreDB 检查db_scorecheck_db_state将任务定义的期望动作evaluation_criteria.actions在一个全新数据库上重放_replay_expected_actions再用_hash_db对重放后的期望库与真实对话后的实际库计算 SHA-256 规范化哈希二者一致得 1.0否则 0.0。不一致时通过_diff_db输出逐字段 diff。也就是说Agent 是否准确、无多余动作地执行了预订/改签/取消最终落在数据库状态上。沟通检查communicate_scorecheck_communicate将任务声明的communicate_info信息项逐一在 assistant 消息文本中查找子串匹配返回命中比例。例如任务 3 要求 Agent 告知 silver 会员 economy 舱可携带 4 件行李4若 Agent 没说出正确数字沟通分就会打折。动作检查action_check参考性check_actions用贪心匹配比对工具日志与期望动作名称 参数子集一致结果仅作信息性诊断不计入最终 reward。成功判定score_tau2_episode要求db_score 1.0 且 communicate_score 1.0才判定 episode 成功失败原因分别记为db_state_mismatch/communicate_mismatch并通过actions_match_rate提供诊断指标。九、策略如何被驱动执行多轮对话编排策略文档虽然不直接出现在运行时代码里但它决定了整个交互的剧本。执行层面由 runner.py 的run_multi_turn驱动在一个线程内循环调用run_agent让 Agent 产出回复与工具调用再用 LLM 驱动的 user_sim.py默认gpt-4.1-mini见 test_tau2_airline.py 中USER_SIM_MODEL扮演客户角色。用户模拟器按 τ-bench 规范渐进式透露信息等待 Agent 追问才给出并维护剧本一致性——任务 3 中用户坚持声称自己是 Gold 会员、要求数字形式答复而数据库实际是 SilverAgent 必须用get_user_details核实事实并拒绝其错误认知。这正印证了策略第七条Always confirms the facts before offering compensation及全局准则不提供主观建议的必要性。会话以三种终止令牌之一收束###STOP###任务完成、###TRANSFER###被转人工、###OUT-OF-SCOPE###场景信息不足对应ConversationResult.terminated_by字段。测试通过 pytest 参数化覆盖 15 个任务TASK_IDS运行方式仓库只读仅介绍查看与运行uv run --group test pytest tests/evals/tau2_airline/ -v --model claude-sonnet-4-6 uv run --group test pytest tests/evals/tau2_airline/ -k task_2 --model claude-sonnet-4-6十、策略阅读与评测写作的要点总结先采集再行动user id、reservation id、取消原因等关键信息必须主动获取用户不知道时用get_user_details、get_reservation_details等工具定位边界条件务必核对basic economy 不可改签、已起飞不可取消、改签不可改起降地/行程类型、乘客数不可变——这些API 不检查的规则全靠 Agent 自觉补偿是稀缺授权只有取消 × $100/人和延误且改签/取消 × $50/人两种补偿路径且只面向 silver/gold、有保险或 business 乘客数据库状态是最终裁判无论对话多么顺畅期望动作重放后的 DB 哈希必须与真实对话后的 DB 哈希完全一致沟通要给出可断言的信息行李件数、价格、金额等数字性结论要落在communicate_info可命中的文本里。进一步阅读策略的落地实现见 domain.py14 个 LangChain 工具与数据模型、评分逻辑见 evaluation.py、对话编排见 runner.py 与 user_sim.py任务剧本与断言见 tasks.json运行入口与系统提示词见 test_tau2_airline.py。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 deepagents 航空客服策略文档（policy.md）全解析：tau2 Airline 评测中的规则约束与执行细节
deepagents 航空客服策略文档policy.md全解析tau2 Airline 评测中的规则约束与执行细节【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本文以 libs/evals/tests/evals/tau2_airline/data/policy.md 为绝对主线逐节拆解这份航空客服 Agent 业务策略。它定义了 Agent 在 book订票、modify改签、cancel取消与 refunds/compensation退款与补偿四类场景下的全部行为边界同时结合同目录下的 domain.py、evaluation.py、test_tau2_airline.py 等源码说明该策略如何被装载进 deepagents 系统提示词、被 14 个 LangChain 工具调用链执行、并被 DB 状态比对 沟通信息检查双维度打分。读完本文你将完整掌握这份策略文档的规则矩阵、其与底层工具实现的对应关系以及 tau2 评测的判定机制。一、策略文档在评测体系中的定位在 deepagents 仓库中这份 policy.md 并非普通的产品说明而是 libs/evals/tests/evals/tau2_airline 评测模块的规则引擎。它由 domain.py 中的load_policy()函数直接读取并原样注入 Agent 系统提示词def load_policy() - str: Load the airline customer service policy. with (_DATA_DIR / policy.md).open() as fp: return fp.read()真正的注入发生在 test_tau2_airline.py 的测试夹具中AGENT_SYSTEM_PROMPT模板把整个策略放进policy.../policy标签内通过create_deep_agent构建带 checkpointer 的 deepagents 图AGENT_SYSTEM_PROMPT \ You are a customer service agent that helps the user according to the policy provided below. Use the available tools to look up information, verify customer identity, and take actions. Always follow the policy. Be helpful, concise, and accurate. policy {domain_policy} /policy\ agent create_deep_agent( modelmodel, toolstools, system_promptAGENT_SYSTEM_PROMPT.format(domain_policypolicy), checkpointerMemorySaver(), )该模块源自 Sierra Research 的 τ-bench / τ²-bench / τ³-benchMIT License见目录内 LICENSE是验证Agent 能否在复杂业务规则约束下合规工作的标准场景。策略文档设置了固定的模拟时间2024-05-15 15:00:00 EST这与 domain.py 中_CURRENT_DATETIME 2024-05-15T15:00:00保持一致保证24 小时取消窗口已起飞航班等时间敏感规则可判定。二、全局行为准则所有动作的第一道门槛policy.md 开头部分是适用于全部场景的通用规则也是评测中最容易被扣分的隐性红线准则原文要点实现印证先确认再执行任何会更新预订数据库的动作订票、改航班、改行李、改舱位、改乘客信息必须先列明动作细节并取得用户明确的 yes对应book_reservation、update_reservation_flights等工具的入参均为用户确认后一次性提交的设计不越界输出不得提供用户或工具之外的信息、知识、流程不得给出主观建议对应 user_sim.py 中模拟用户不编造场景外信息的对称约束一次只做一件事一次只能调用一个工具调用工具时不得同时回复用户对应run_multi_turn单轮单次run_agent的驱动方式拒绝违规请求对违反本策略的请求必须拒绝大量测试任务的nl_assertions就是检查Agent 是否拒绝转人工仅当请求超出自身动作范围时才转人工先调用transfer_to_human_agents再发送固定话术YOU ARE BEING TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON.domain.py 中transfer_to_human_agents(summary)工具以及 user_sim.py 中###TRANSFER###终止令牌与之呼应从源码结构看transfer_to_human_agents是 14 个工具中唯一一个结束会话性质的出口用户模拟器识别到转人工时输出###TRANSFER###令牌双方通过这一协议完成场景收束。三、领域基础知识User、Flight、Reservation 三个数据模型策略文档紧接着定义了评测世界的三个核心实体这些实体在 domain.py 中被建模为 Pydantic 模型并最终由db.json见 libs/evals/tests/evals/tau2_airline/data/db.json装载User用户每个用户包含user id、email、地址、出生日期、支付方式、会员等级、预订号列表。两类枚举值是策略计算的关键支付方式三种credit card信用卡、gift card礼品卡、travel certificate旅行凭证。会员等级三种regular、silver、gold——直接决定免费托运行李额度见下文行李配额矩阵。对应源码User模型payment_methods: dict[str, PaymentMethod]PaymentMethod 是 CreditCard | GiftCard | Certificate 的联合类型membership: MembershipLevel。Flight航班航班属性航班号、出发地、目的地、计划起飞/到达时间均为当地时间。同一航班在多个日期各有状态available未起飞可订列出各舱位余座与价格delayed / on time未起飞但不可预订flying已起飞未落地不可预订另有 landed、cancelled 状态见 domain.py 的FlightDateStatus联合类型。舱位三种basic economy基础经济舱独立于 economy、economy、business。余座与价格按舱位分别列出。源码中的_search_direct_flights正是按此实现筛选逻辑if flight.dates[date].status ! available: continue即只有 available 状态才进入可订结果集。Reservation预订每个预订包含reservation id、user id、trip type行程类型、flights、passengers、payment methods、created time创建时间、baggages、travel insurance information旅行保险信息。行程类型两种one way单程、round trip往返。对应源码Reservation模型字段flight_type、cabin、flights、passengers、payment_history、created_at、total_baggages、nonfree_baggages、insurance、status。四、Book flight订票策略最密集的业务流订票流程是策略文档中规则最密集的部分Agent 必须按顺序采集信息并严格遵守约束。policy.md 的规定与 domain.py 中book_reservation工具的输入校验一一对应。信息采集顺序首先必须取得user id然后询问trip type、origin出发地、destination目的地依次确认舱位、乘客、支付方式、托运行李、旅行保险。对应book_reservation的完整入参 schemaBookReservationInputuser_id, origin, destination, flight_type, cabin, flights, passengers, payment_methods, total_baggages, nonfree_baggages, insurance。舱位约束同一预订内所有航班舱位必须一致源码中Reservation.cabin是单一字段天然保证这一点。乘客约束每个预订最多 5 名乘客需收集每位乘客的 first name、last name、date of birth对应Passenger模型的 first_name/last_name/dob所有乘客必须乘坐相同的航班、相同的舱位源码按len(parsed_passengers)统一计算座位与价格。支付约束每个预订最多 1 张旅行凭证 1 张信用卡 3 张礼品卡旅行凭证的剩余金额不可退款源码中证书扣款后直接user.payment_methods.pop(pm.payment_id)移除不会找零出于安全考虑所有支付方式必须已存在于用户档案中源码逐一校验pm.payment_id not in user.payment_methods即报错。免费托运行李配额矩阵核心表格务必完整继承配额由订票用户的会员等级×每位乘客的舱位共同决定订票用户会员等级basic economy 乘客economy 乘客business 乘客regular0 件1 件2 件silver1 件2 件3 件gold2 件3 件4 件超出免费额度的每件行李 50 美元源码total_price 50 * nonfree_baggages与此一致不得添加用户不需要的托运行李——这是典型过度服务陷阱评测中会通过nl_assertions检查。旅行保险Agent必须主动询问用户是否购买旅行保险每人 30 美元购买后若因健康或天气原因取消航班可全额退款源码total_price 30 * len(parsed_passengers)按乘客数计费。五、Modify flight改签分段规则与API 不检查陷阱改签场景首先要求取得user id 与 reservation id用户必须提供 user id若用户不知道 reservation idAgent 应使用工具协助定位get_user_details返回用户的预订列表。改航班Change flightsbasic economy 航班不可改签其他预订可改签但不得改变 origin、destination、trip type部分航段可以保留但保留航段的价格不会按当前价格更新源码update_reservation_flights中existing逻辑保留航段沿用existing.price关键警告API 不会替 Agent 校验这些规则so the agent must make sure the rules apply before calling the API——即策略合规是 Agent 自身的责任这正是评测的核心考察点。对应工具为update_reservation_flights(reservation_id, cabin, flights, payment_id)其参数描述明确要求All flight segments must be included (even unchanged ones)改签时必须提交全部航段含未改动的。改舱位Change cabin若预订中任一航班已起飞则不能改舱位其他情况含 basic economy 预订可在不改变航班的前提下改舱位同一预订内所有航段舱位必须一致不能只改某一个航段改后价格更高 → 用户需补差价改后价格更低 → 用户应获得差额退款。改行李与保险Change baggage and insurance行李只能增加不能减少预订创建后不能再添加保险。改乘客Change passengers可以修改乘客信息但不能修改乘客数量策略明确强调Even a human agent cannot modify the number of passengers——源码update_reservation_passengers中if len(parsed) ! len(reservation.passengers): raise ToolException(Number of passengers does not match)硬性校验了这一点。支付若航班被更改用户需提供一张礼品卡或信用卡作为支付/退款方式且必须已在用户档案中源码_payment_for_update同时拒绝证书Certificate cannot be used to update reservation。六、Cancel flight取消四种合法理由与转人工边界取消场景同样要求 user id reservation id未知则用工具定位且必须取得取消原因change of plan、airline cancelled flight、other。硬性边界若航班任何部分已经起飞Agent 无法处理必须转人工。四种可取消条件满足任一即可预订发生在最近 24 小时内航班被航空公司取消是business 舱位的预订用户购买了旅行保险且取消原因在保险覆盖范围内健康或天气原因。同样有API 不检查警告cancel_reservation工具本身不做策略判断Agent 必须在调用前自行核对规则。退款退款将在5 至 7 个工作日内原路退回源码cancel_reservation向payment_history追加等额负值退款记录即按原支付方式冲销。七、Refunds and Compensation退款与补偿谨慎授予的证书逻辑补偿场景是防滥用设计的典型策略强调不主动提出补偿、补偿前必须核实事实不主动提供补偿除非用户明确要求不向regular 会员 无保险 乘坐基础经济舱的用户补偿补偿前总是先确认事实仅当用户是 silver/gold 会员或购买了保险或乘坐 business 舱位时才可补偿。两种允许的补偿均为 certificate 证书形式对应send_certificate(user_id, amount)工具场景前提金额预订中航班被取消且用户投诉核实事实后$100 × 乘客数预订中航班延误且用户投诉并要求改签/取消核实事实并完成改签/取消后$50 × 乘客数除上述理由外不得因任何其他理由提供补偿。八、从策略到评测DB COMMUNICATE 双重打分机制策略合规与否如何被机器判定evaluation.py 实现了 τ-bench 风格的评估管线evaluate_task的最终奖励为reward db_score * communicate_scoreDB 检查db_scorecheck_db_state将任务定义的期望动作evaluation_criteria.actions在一个全新数据库上重放_replay_expected_actions再用_hash_db对重放后的期望库与真实对话后的实际库计算 SHA-256 规范化哈希二者一致得 1.0否则 0.0。不一致时通过_diff_db输出逐字段 diff。也就是说Agent 是否准确、无多余动作地执行了预订/改签/取消最终落在数据库状态上。沟通检查communicate_scorecheck_communicate将任务声明的communicate_info信息项逐一在 assistant 消息文本中查找子串匹配返回命中比例。例如任务 3 要求 Agent 告知 silver 会员 economy 舱可携带 4 件行李4若 Agent 没说出正确数字沟通分就会打折。动作检查action_check参考性check_actions用贪心匹配比对工具日志与期望动作名称 参数子集一致结果仅作信息性诊断不计入最终 reward。成功判定score_tau2_episode要求db_score 1.0 且 communicate_score 1.0才判定 episode 成功失败原因分别记为db_state_mismatch/communicate_mismatch并通过actions_match_rate提供诊断指标。九、策略如何被驱动执行多轮对话编排策略文档虽然不直接出现在运行时代码里但它决定了整个交互的剧本。执行层面由 runner.py 的run_multi_turn驱动在一个线程内循环调用run_agent让 Agent 产出回复与工具调用再用 LLM 驱动的 user_sim.py默认gpt-4.1-mini见 test_tau2_airline.py 中USER_SIM_MODEL扮演客户角色。用户模拟器按 τ-bench 规范渐进式透露信息等待 Agent 追问才给出并维护剧本一致性——任务 3 中用户坚持声称自己是 Gold 会员、要求数字形式答复而数据库实际是 SilverAgent 必须用get_user_details核实事实并拒绝其错误认知。这正印证了策略第七条Always confirms the facts before offering compensation及全局准则不提供主观建议的必要性。会话以三种终止令牌之一收束###STOP###任务完成、###TRANSFER###被转人工、###OUT-OF-SCOPE###场景信息不足对应ConversationResult.terminated_by字段。测试通过 pytest 参数化覆盖 15 个任务TASK_IDS运行方式仓库只读仅介绍查看与运行uv run --group test pytest tests/evals/tau2_airline/ -v --model claude-sonnet-4-6 uv run --group test pytest tests/evals/tau2_airline/ -k task_2 --model claude-sonnet-4-6十、策略阅读与评测写作的要点总结先采集再行动user id、reservation id、取消原因等关键信息必须主动获取用户不知道时用get_user_details、get_reservation_details等工具定位边界条件务必核对basic economy 不可改签、已起飞不可取消、改签不可改起降地/行程类型、乘客数不可变——这些API 不检查的规则全靠 Agent 自觉补偿是稀缺授权只有取消 × $100/人和延误且改签/取消 × $50/人两种补偿路径且只面向 silver/gold、有保险或 business 乘客数据库状态是最终裁判无论对话多么顺畅期望动作重放后的 DB 哈希必须与真实对话后的 DB 哈希完全一致沟通要给出可断言的信息行李件数、价格、金额等数字性结论要落在communicate_info可命中的文本里。进一步阅读策略的落地实现见 domain.py14 个 LangChain 工具与数据模型、评分逻辑见 evaluation.py、对话编排见 runner.py 与 user_sim.py任务剧本与断言见 tasks.json运行入口与系统提示词见 test_tau2_airline.py。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考