liqiang
b119135836
Build latest book artifacts / build (push) Canceled after 0s
dependency resolution / resolve (3.11) (push) Canceled after 0s
dependency resolution / resolve (3.13) (push) Canceled after 0s
deploy-pages / build (push) Canceled after 0s
deploy-pages / deploy (push) Canceled after 0s
i18n consistency check / check (push) Canceled after 0s
provider adoption tests / test (chapter2/context-compression) (push) Canceled after 0s
provider adoption tests / test (chapter2/prompt-injection) (push) Canceled after 0s
provider adoption tests / test (chapter2/system-hint) (push) Canceled after 0s
provider adoption tests / test (chapter3/log-sanitization) (push) Canceled after 0s
web-search-agent tests / test (push) Canceled after 0s
web-search-agent tests / agentbook (push) Canceled after 0s
207 lines
12 KiB
Markdown
207 lines
12 KiB
Markdown
# Cursor Chat: ai-agent-book
|
||
|
||
## Metadata
|
||
- **Project**: ai-agent-book
|
||
- **Path**: `/Users/boj`
|
||
- **Date**: 2025-10-14 19:13:00
|
||
- **Session ID**: `0e3d4226-e0e8-4062-ab43-9dda5d3615f0`
|
||
|
||
## Conversation
|
||
|
||
### 👤 You
|
||
|
||
在客户服务、政策执行等领域,业务流程往往包含大量的条件判断和规则。传统的做法是将这些规则以自然语言的形式写成操作手册或政策文档。然而,当 Agent 需要理解并执行这些规则时,自然语言的模糊性就会导致各种问题。Agent 可能对规则产生错误的理解,可能在边界情况下做出不一致的判断,或是陷入"马虎思考"(sloppy thinking)——看似理解了规则,实则遗漏了关键的条件或例外情况。
|
||
|
||
一个更好的方案是将业务流程以伪代码或真实代码的形式精确表示。以航空公司的退款政策为例:与其用自然语言描述"如果航班取消且是我们的责任,并且乘客没有已经使用过部分行程,则全额退款",不如将其表示为一段清晰的 if-then-else 逻辑。这段代码可以是可执行的,也可以是供 Agent 阅读理解的伪代码,关键在于它消除了自然语言的歧义。更进一步,当 Agent 需要判断一个具体案例是否符合退款条件时,与其让 Agent 在思维链中进行文本推理,不如让 Agent 生成一段真实的代码,将案例的具体参数(航班状态、取消原因、乘客使用情况)输入到这段业务逻辑代码中,通过执行代码来获得判断结果。代码的执行结果是确定的、可验证的,这从根本上杜绝了幻觉和模糊推理,大大提升了决策的准确性和一致性。
|
||
|
||
--
|
||
修改这一部分，业务逻辑校验代码不应该是在每次 Agent 运行时生成的，而应该是根据 policy 预先生成的校验代码，模型在调用工具之前，也必须调用额外的校验工具，输入这些参数（例如 退款校验 等），可以在文中生成一个校验工具的例子。
|
||
|
||
# Airline Agent Policy
|
||
|
||
The current time is 2024-05-15 15:00:00 EST.
|
||
|
||
As an airline agent, you can help users book, modify, or cancel flight reservations.
|
||
|
||
- Before taking any actions that update the booking database (booking, modifying flights, editing baggage, upgrading cabin class, or updating passenger information), you must list the action details and obtain explicit user confirmation (yes) to proceed.
|
||
|
||
- You should not provide any information, knowledge, or procedures not provided by the user or available tools, or give subjective recommendations or comments.
|
||
|
||
- You should only make one tool call at a time, and if you make a tool call, you should not respond to the user simultaneously. If you respond to the user, you should not make a tool call at the same time.
|
||
|
||
- You should deny user requests that are against this policy.
|
||
|
||
- You should transfer the user to a human agent if and only if the request cannot be handled within the scope of your actions.
|
||
|
||
## Domain Basic
|
||
|
||
- Each user has a profile containing user id, email, addresses, date of birth, payment methods, reservation numbers, and membership tier.
|
||
|
||
- Each reservation has an reservation id, user id, trip type (one way, round trip), flights, passengers, payment methods, created time, baggages, and travel insurance information.
|
||
|
||
- Each flight has a flight number, an origin, destination, scheduled departure and arrival time (local time), and for each date:
|
||
- If the status is "available", the flight has not taken off, available seats and prices are listed.
|
||
- If the status is "delayed" or "on time", the flight has not taken off, cannot be booked.
|
||
- If the status is "flying", the flight has taken off but not landed, cannot be booked.
|
||
|
||
## Book flight
|
||
|
||
- The agent must first obtain the user id, then ask for the trip type, origin, destination.
|
||
|
||
- Passengers: Each reservation can have at most five passengers. The agent needs to collect the first name, last name, and date of birth for each passenger. All passengers must fly the same flights in the same cabin.
|
||
|
||
- Payment: each reservation can use at most one travel certificate, at most one credit card, and at most three gift cards. The remaining amount of a travel certificate is not refundable. All payment methods must already be in user profile for safety reasons.
|
||
|
||
- Checked bag allowance: If the booking user is a regular member, 0 free checked bag for each basic economy passenger, 1 free checked bag for each economy passenger, and 2 free checked bags for each business passenger. If the booking user is a silver member, 1 free checked bag for each basic economy passenger, 2 free checked bag for each economy passenger, and 3 free checked bags for each business passenger. If the booking user is a gold member, 2 free checked bag for each basic economy passenger, 3 free checked bag for each economy passenger, and 3 free checked bags for each business passenger. Each extra baggage is 50 dollars.
|
||
|
||
- Travel insurance: the agent should ask if the user wants to buy the travel insurance, which is 30 dollars per passenger and enables full refund if the user needs to cancel the flight given health or weather reasons.
|
||
|
||
## Modify flight
|
||
|
||
- The agent must first obtain the user id and the reservation id.
|
||
|
||
- Change flights: Basic economy flights cannot be modified. Other reservations can be modified without changing the origin, destination, and trip type. Some flight segments can be kept, but their prices will not be updated based on the current price. The API does not check these for the agent, so the agent must make sure the rules apply before calling the API!
|
||
|
||
- Change cabin: all reservations, including basic economy, can change cabin without changing the flights. Cabin changes require the user to pay for the difference between their current cabin and the new cabin class. Cabin class must be the same across all the flights in the same reservation; changing cabin for just one flight segment is not possible.
|
||
|
||
- Change baggage and insurance: The user can add but not remove checked bags. The user cannot add insurance after initial booking.
|
||
|
||
- Change passengers: The user can modify passengers but cannot modify the number of passengers. This is something that even a human agent cannot assist with.
|
||
|
||
- Payment: If the flights are changed, the user needs to provide one gift card or credit card for payment or refund method. The agent should ask for the payment or refund method instead.
|
||
|
||
## Cancel flight
|
||
|
||
- The agent must first obtain the user id, the reservation id, and the reason for cancellation (change of plan, airline cancelled flight, or other reasons)
|
||
|
||
- All reservations can be cancelled within 24 hours of booking, or if the airline cancelled the flight. Otherwise, basic economy or economy flights can be cancelled only if travel insurance is bought and the condition is met, and business flights can always be cancelled. The rules are strict regardless of the membership status. The API does not check these for the agent, so the agent must make sure the rules apply before calling the API!
|
||
|
||
- The agent can only cancel the whole trip that is not flown. If any of the segments are already used, the agent cannot help and transfer is needed.
|
||
|
||
- The refund will go to original payment methods in 5 to 7 business days.
|
||
|
||
## Refund
|
||
|
||
- If the user is silver/gold member or has travel insurance or flies business, and complains about cancelled flights in a reservation, the agent can offer a certificate as a gesture after confirming the facts, with the amount being $100 times the number of passengers.
|
||
|
||
- If the user is silver/gold member or has travel insurance or flies business, and complains about delayed flights in a reservation and wants to change or cancel the reservation, the agent can offer a certificate as a gesture after confirming the facts and changing or cancelling the reservation, with the amount being $50 times the number of passengers.
|
||
|
||
- Do not proactively offer these unless the user complains about the situation and explicitly asks for some compensation. Do not compensate if the user is regular member and has no travel insurance and flies (basic) economy.
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
我来帮你修改这部分内容。首先让我查看当前的 chapter5.md 文件，定位到需要修改的部分。
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
我来修改这部分内容，根据你的要求，将其改为预先生成的校验代码，并添加一个校验工具的例子。
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完成！我已经根据你的要求修改了这部分内容，主要改动包括：
|
||
|
||
## 核心改动
|
||
|
||
1. **明确校验代码是预先生成的**：强调这些校验代码"不是在每次 Agent 运行时临时生成的,而是根据业务政策预先生成并固化的"
|
||
|
||
2. **强制校验流程**：说明"Agent 在执行任何关键操作(如取消订单、发放补偿)之前,必须先调用相应的校验工具"
|
||
|
||
3. **完整的校验工具示例**：提供了一个 `validate_cancellation` 函数，完整实现了航空公司取消政策的所有规则：
|
||
- 已使用航段检查
|
||
- 24小时内预订可取消
|
||
- 航空公司取消的航班
|
||
- 商务舱规则
|
||
- 基础经济舱/经济舱的保险要求
|
||
|
||
4. **清晰的工作流程**：列出了 Agent 使用校验工具的4步流程
|
||
|
||
5. **明确优势**：总结了这种方式的四个核心优势（确定性、一致性、可维护性、可审计性）
|
||
|
||
6. **扩展性说明**：提到可以创建其他类似的校验工具（改签、补偿等）
|
||
|
||
这样的修改更符合实际的工程实践，将业务规则作为预先编写好的代码工具，而不是让 Agent 临时生成，大大提升了可靠性和可维护性。
|
||
|
||
---
|
||
|
||
### 👤 You
|
||
|
||
1. 例子中不需要包含 refund_method，return 的结构在一行中，紧凑一些，以便排版到书里
|
||
2. 修改 实验 5.4 的描述，不要太长，实验中不要包含例子
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
让我先查看当前实验 5.4 的内容：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
现在我来修改实验 5.4 的描述，使其与前面的修改保持一致：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完美！我已经完成了实验 5.4 的修改。主要改进包括：
|
||
|
||
## 关键变化
|
||
|
||
1. **标题更新**：从"代码化知识"改为"预生成校验工具"，更准确地反映技术方案
|
||
|
||
2. **对比更清晰**：
|
||
- **控制组**：自然语言规则 + Agent 推理判断
|
||
- **实验组**：预生成校验工具 + 强制调用流程
|
||
|
||
3. **技术方案更具体**：
|
||
- 列出三个具体的校验工具（取消、改签、补偿）
|
||
- 提供了完整的工具调用代码示例
|
||
- 说明了"决策依据转移"——从模型推理转移到工具执行
|
||
- 强调了强制校验流程（
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
我来帮你修改这两处内容，让例子更紧凑，实验描述更简洁。
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
现在修改实验 5.4 的描述，让它更简洁：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完成！我已经完成了以下修改：
|
||
|
||
## 修改 1：简化代码例子
|
||
|
||
- 去掉了返回值中的 `refund_method` 字段
|
||
- 将所有 `return` 语句改为单行紧凑格式
|
||
- 简化了 docstring 和 reason 文本
|
||
- 代码从 60+ 行缩减到 35 行左右，更适合书籍排版
|
||
|
||
## 修改 2：简化实验 5.4 的技术方案
|
||
|
||
将原来的方案从较长的描述改为一句话概括：
|
||
- 明确对照实验的设计：控制组 vs 实验组
|
||
- 强调实验组使用预先生成的校验工具（与前文一致）
|
||
- 突出核心差异：工具的确定性结果 vs 文本推理
|
||
- 去掉了所有具体例子和代码片段
|
||
|
||
现在整个内容更紧凑、更适合书籍排版，同时保持了逻辑连贯性。
|
||
|
||
---
|
||
|
||
|
||
*Exported from [Cursor View](https://github.com/saharmor/cursor-view)* |