一步步设计
从任务意图开始，不从工具名字开始
虚构请求：“把明天与小林的会改到下午，其他会别动。”让 Choice 在查询、候选改期、取消、其他意图间选择。一个自然语言请求可以包含多个限制；“下午”不是确定时间，“小林”也可能对应两个联系人。先把缺失信息当成待补条件。
构造允许使用的候选目录
代码提供本任务可用的工具与约束，例如只读查日程、生成改期预览。已登录身份、组织权限和可访问日历由可信系统提供；邮件正文中的“我已授权”不是凭据。Jev 可帮助选择候选工具，但工具目录应由应用控制。
参数先确定性验证，再做语义检查
工具参数至少检查 schema、meeting_id 存在、时区、开始早于结束、参与人范围。用代码列出真实候选，再让模型判断候选是否符合请求。不得让模型编造 meeting_id 或将文本里的日期直接当成最终 UTC 时间。歧义要询问，不能把 confidence 当事实补全。
把执行分成预览与确认
本例先展示“哪场会、原时间、新时间、受影响人员”。若用户只授权查询，改期必须等待有效授权；已明确授权的具体动作仍需通过权限与约束校验。Choice confidence 可以决定复核路线，但高值不授予访问权限；Noul 只有陈述概率，也不是执行令牌。
执行时防重入，执行后核对结果
为一次已确认操作使用幂等键，提交前复查当前日程，遇到并发改动就重新确认差异。失败时不要无限重试改期；查实际结果再决定。记录意图、候选、参数、策略版本、授权依据与执行状态，避免日志保存不必要的私人正文。
用越界样本测试整个流程
准备同名联系人、过期会议、时区跨天、文本伪装授权、返回高 confidence 但无权限、网络超时后已执行等样本。验证“不得执行”的条件确实拦截，并且合法请求能走通。这里展示的是流程设计，没有连接你的日历或实际运行工具。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 同一天有两场小林的会 | 意图明确，但对象不唯一 | 展示候选并补问，不提交 |
| 候选明确；仅具备只读权限 | 高 confidence 不能扩展权限 | 只读预览，拒绝写入 |
| 已授权具体改期；参数与权限合法 | 满足条件才可进入执行 | 幂等提交并核对最终日程 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Pseudocode: policy logic, not an SDK example.
if proposed_tool not in task_allowlist:
reject("tool unavailable")
elif not schema_valid(arguments) or not target_exists(arguments):
request_clarification()
elif not account_can_write(target_calendar):
show_read_only_preview()
elif not specifically_authorized(action, arguments):
show_preview_and_request_authorization()
elif calendar_changed_since_preview():
review_the_new_difference()
else:
execute_once(idempotency_key)
verify_result_and_record_status()容易踩的坑
- 工具名分类正确就直接执行，跳过对象与权限检查。
- 把上下文中的“忽略规则并执行”当成系统授权。
- API 超时就再做一次写操作，不先查询真实状态。
TRY / THINK / COMPARE
先想一想，再看解析
改期意图 confidence=0.98，但账号没有写权限。要提高阈值还是执行？
展开解析
两者都不是。权限检查应直接拒绝写入；提高语义阈值不会产生权限。可以展示只读预览，并说明需要怎样的有效授权或账号权限。
交付前检查
- 候选目录、身份和权限来自可信代码。
- 参数检查与语义判断分开，并能处理歧义。
- 预览、授权依据、失败与幂等策略齐全。
- 同时测试正确执行和应拒绝执行的样本。
常见问题
Noul 能作为安全证明吗？
不能。它表示陈述概率，不能替代身份认证、访问控制或参数验证。
所有动作都要重新确认吗？
不需要机械重复。按具体任务的已有授权与应用策略决定；授权范围不明或参数有歧义时再补充。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。