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
190 lines
9.0 KiB
Markdown
190 lines
9.0 KiB
Markdown
# Cursor Chat: ai-agent-book
|
||
|
||
## Metadata
|
||
- **Project**: ai-agent-book
|
||
- **Path**: `/Users/boj`
|
||
- **Date**: 2025-10-16 23:13:50
|
||
- **Session ID**: `3b070cab-d0ad-4455-9d95-9180b8c67cad`
|
||
|
||
## Conversation
|
||
|
||
### 👤 You
|
||
|
||
1. Agent增加业务规则的约束，以下两种方式的比较：system prompt中涵盖业务规则、代码化的业务规则？哪种实际上用的更多，为什么？
|
||
|
||
2. 自然语言规则代码化，虽然判断时更加精确，但是“代码+tool description”所消耗的token会多很多，这是否会限制规则代码化的应用，特别是规则很多的时候：就如课上的例子中，`validate_cancellation` “校验工具代码+tool description”比“基础经济舱和经济舱航班只有在购买了旅行保险且符合条件时才能取消，商务舱航班总是可以取消”的text长度多很多。
|
||
|
||
--
|
||
在 “精确表达复杂业务规则” 中，要澄清这两个问题：
|
||
system prompt 里面仍然需要有业务规则，有业务规则一是方便跟用户解释 policy，二是方便根据 policy 找到变通方案，如果没有业务规则，校验一次失败，试第二次调用工具又失败，就会严重影响效率。
|
||
|
||
另外需要修改例子和描述，执行和校验工具合并，在执行的时候，先按照规则校验，校验通过再执行，不通过就拒绝。执行所需的参数和校验所需的参数都由模型给出。模型在思考给出这些校验所需参数的时候，又可能自然就注意到了规则中的条件（进而根本不会调用这个工具），相当于这些要求模型一个个输出的检查参数是 checklist，强迫模型思考这些条件。
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
I'll help you revise the "精确表达复杂业务规则" section in chapter5.md to clarify these important points. Let me first read the current content to understand what needs to be modified.
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
I'll help you revise the "精确表达复杂业务规则" section in chapter 5 to address these important clarifications. Let me update the content:
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
Let me try again with the correct Chinese punctuation:
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
Perfect! Now let me also update the experiment description to align with the new approach:
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
Excellent! Let me now check for any linting issues in the updated file:
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
Perfect! I've successfully revised the "精确表达复杂业务规则" section in chapter 5. Here's a summary of the changes I made to address your concerns:
|
||
|
||
## Key Changes:
|
||
|
||
### 1. **Added Section: "自然语言规则 vs 代码化规则：互补而非替代"**
|
||
- **Clarified that system prompts MUST still contain business rules** for two key reasons:
|
||
- To enable the Agent to **explain policies** to users
|
||
- To enable the Agent to **find workarounds** when direct operations are blocked
|
||
- To allow preliminary judgment before calling tools, avoiding blind attempts
|
||
- Explained that natural language and codified rules are **complementary, not mutually exclusive**
|
||
- Natural language provides flexibility for reasoning and communication
|
||
- Codified rules provide precision and reliability for execution
|
||
|
||
### 2. **Added Section: "代码化规则的 Token 消耗考量"**
|
||
- Addressed the token consumption concern comprehensively:
|
||
- **Codified rules aren't always longer**: Natural language rules often require extensive clarifications for edge cases
|
||
- **Higher first-attempt success rate**: Avoids expensive trial-and-error cycles that accumulate tokens
|
||
- **Tool descriptions can be optimized**: Don't need to explain every branch—the code itself is the precise expression
|
||
- **Layered approach**: Codify only critical/high-frequency/error-prone rules; keep minor rules in natural language
|
||
- Concluded that token cost shouldn't be the limiting factor—the key is identifying which rules deserve codification
|
||
|
||
### 3. **Revised Section: "合并校验与执行：让参数成为思考的 Checklist"**
|
||
- **Changed from separate validation tool to merged execution+validation tool**
|
||
- Renamed from `validate_cancellation` to `cancel_reservation`
|
||
- The tool now:
|
||
- Requires all validation parameters (cabin_class, has_insurance, booking_time, etc.)
|
||
- Validates internally first
|
||
- Executes only if validation passes
|
||
- Rejects with reason if validation fails
|
||
- **Emphasized the "checklist" effect**: When the model prepares these parameters, it's forced to think about each condition
|
||
- **Key insight**: In many cases, the model will recognize violations while preparing parameters and **won't even call the tool**, instead explaining the policy and suggesting alternatives to the user
|
||
- **Three-layer defense mechanism**:
|
||
1. Natural language rules in system prompt (for understanding and communication)
|
||
2. Required parameters as checklist (forces thinking during preparation)
|
||
3. Codified validation logic (final gatekeeper)
|
||
|
||
### 4. **Updated Experiment 5.4**
|
||
- Revised to reflect the new approach
|
||
- Added evaluation metrics including "invalid tool calls" (violations that should have been recognized during parameter preparation)
|
||
- Expected result now emphasizes observing the model's self-recognition of violations during parameter preparation
|
||
|
||
The revised section now provides a comprehensive, balanced view that addresses both your theoretical questions (which approach is used more and why) and practical concerns (token consumption), while presenting a sophisticated design that combines the best of both worlds.
|
||
|
||
---
|
||
|
||
### 👤 You
|
||
|
||
代码化规则的 Token 消耗考量 这块不对，原始 prompt 中仍然是自然语言，不是代码，代码仅在 validation 工具中存在
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
您说得对！我理解有误。让我修正"代码化规则的 Token 消耗考量"这一节：
|
||
|
||
在实际设计中，**系统提示词中始终是自然语言规则**，代码化的规则只存在于工具的实现中。所以 token 消耗的对比应该是：
|
||
|
||
- **纯自然语言方案**：系统提示词中的自然语言规则
|
||
- **代码化方案**：系统提示词中的自然语言规则 + 工具描述（参数说明等）
|
||
|
||
让我修正这部分内容：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
感谢您的指正！我已经修正了"代码化规则的 Token 消耗考量"这一节。现在的论述更准确了：
|
||
|
||
**修正的关键点：**
|
||
|
||
1. **明确承认 token 增加是真实的**：代码化方案确实会增加 token 消耗（系统提示词中的自然语言 + 工具描述）
|
||
|
||
2. **强调工具描述可以简洁**：工具描述的重点是"需要什么参数"而非"业务规则是什么"，因为规则已经在系统提示词的自然语言部分说明了
|
||
|
||
3. **从任务生命周期角度权衡**：虽然单次调用 token 增加，但通过提高首次成功率、避免反复试错，整体可能反而节省 token
|
||
|
||
4. **分层处理策略**：只对关键规则代码化，次要规则保持纯自然语言
|
||
|
||
5. **上下文窗口扩大的趋势**：随着技术发展，这个问题的重要性在降低
|
||
|
||
让我检查一下是否有 lint 错误：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完成！现在"代码化规则的 Token 消耗考量"这一节的论述更加准确和诚实了。它承认了 token 增加是真实的，但从多个角度（工具描述的简洁性、整体任务效率、分层策略、技术发展趋势）来说明为什么这不应该成为阻止应用的主要因素。
|
||
|
||
---
|
||
|
||
### 👤 You
|
||
|
||
代码化规则的真正价值在于**大幅提高首次成功率** 这里的关键问题是，如果不做代码化校验，模型可能做了错误的事情，导致严重后果
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
您说得非常对！我把重点搞错了。代码化规则的核心价值不是"效率提升"，而是**防止错误操作导致的严重后果**。让我修正这段：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完美！我已经修正了这段的核心论点。现在强调的重点是：
|
||
|
||
**关键修改：**
|
||
|
||
1. **明确代码化规则的真正价值**：不是"提高首次成功率"这种效率问题，而是**防止错误操作导致的严重后果**
|
||
|
||
2. **强调操作的不可逆性**：取消订单、转账、删除数据等操作一旦执行就无法撤销
|
||
|
||
3. **列举具体的严重后果**：
|
||
- 违反业务政策造成财务损失
|
||
- 违反法律法规引发合规风险
|
||
- 损害用户权益导致信任危机
|
||
- 破坏数据完整性造成系统故障
|
||
|
||
4. **重新定位 token 成本**：安全保障的价值远远超过 token 成本
|
||
|
||
5. **优先级指导**：优先为涉及高风险或不可逆操作的规则提供代码化校验
|
||
|
||
让我检查一下是否有 lint 错误：
|
||
|
||
---
|
||
|
||
### 🤖 Cursor Assistant
|
||
|
||
完成！现在这段论述的重点正确了：代码化规则的核心价值是**安全性保障**——防止模型理解偏差导致不可逆的严重后果，而不仅仅是提高效率。这对于涉及金融、医疗、法律合规等高风险场景尤为重要。
|
||
|
||
---
|
||
|
||
|
||
*Exported from [Cursor View](https://github.com/saharmor/cursor-view)* |