参考答案
核对日期：2026-05-13。
专题学习入口：
1. 阶段练习参考方向
1.1 工具 schema 练习
合格 schema 不只是参数列表，还应包含权限、幂等性、错误码和示例。
{
"name": "create_ticket_draft",
"permission": "write_draft",
"idempotent": true,
"side_effect": "draft_only",
"input_schema": {
"type": "object",
"required": ["customer_id", "title", "description"],
"properties": {
"customer_id": { "type": "string" },
"title": { "type": "string" },
"description": { "type": "string" }
}
},
"error_codes": ["PERMISSION_DENIED", "VALIDATION_ERROR", "NOT_FOUND"],
"example": {
"customer_id": "cus_123",
"title": "退款申请草稿",
"description": "用户反馈重复扣费，需要人工审核。"
}
}
高风险工具必须显式标注是否需要审批、是否可撤销、执行后影响范围。
1.2 只读 Agent Loop
参考伪代码：
state = {"steps": [], "evidence": [], "answer": None}
for step in range(8):
action = model.decide(goal, state, allowed_tools=["search", "read"])
trace(action)
if action.tool not in ["search", "read"]:
return escalate("tool_not_allowed")
result = call_tool(action)
trace(result)
state["steps"].append({"action": action, "result": result})
if result.evidence:
state["evidence"].extend(result.evidence)
if enough_evidence(state["evidence"]):
return answer_with_citations(state["evidence"])
return refuse("没有找到足够证据")
关键是最大步数、工具白名单、trace、证据判断和拒答。
1.3 写操作审批设计
退款申请审批卡片应包含：
- 用户、订单、金额、原因、历史记录。
- Agent 建议动作和依据。
- 风险等级和影响范围。
- 可撤销方式和预计生效时间。
- 引用证据和工具调用记录。
审批人应由权限系统决定。审批后由后端固定 Workflow 执行，不让模型直接执行资金动作。撤销需要反向流程和审计记录。
1.4 失败轨迹分析
示例失败轨迹：
目标：为用户查询退款资格
Step 1：搜索政策，正确
Step 2：读取订单，正确
Step 3：模型把“可申请退款”误解成“立即退款”
Step 4：调用 refund_execute，高风险越权
应标注：
- 偏离目标：Step 3。
- 工具调用错误：Step 4 选择了真实退款工具。
- 状态污染：把草稿建议写成已批准动作。
- guardrail：高风险工具必须审批，Agent 不应拥有执行权限。
- eval：加入“可申请但未批准”的退款样例，检查是否只创建审批草稿。
1.5 Agent vs Workflow 判断
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 发票字段抽取 | 单次 LLM / Workflow | 路径固定，schema 清晰 |
| 固定条件审批 | Workflow | 规则明确，风险高 |
| 代码库 bug 定位 | Agent | 需要搜索、读取、运行测试和迭代 |
| 企业制度问答 | RAG | 以检索和引用为核心 |
| 大规模资料研究 | Agent 或多 Agent | 可分解搜索、阅读、汇总，但要 trace 和合并规则 |
2. 项目评分样例
高分 Agent 设计应具备：
- 能解释为什么不是普通 Workflow。
- 工具 schema 有权限、错误、幂等和示例。
- 状态对象可恢复，不依赖无限聊天历史。
- 有最大步数、预算、停止条件和升级条件。
- 人类在环展示证据、影响和撤销策略。
- 轨迹 eval 覆盖工具选择、参数、状态和越权。
不合格表现：
- 一上来多 Agent，但没有职责和合并规则。
- 模型可直接调用高风险写工具。
- 没有 trace，失败无法复盘。
- 让 Prompt 负责权限。
3. 验收题参考答案
- Agent 和 Workflow 的核心区别是什么？
Workflow 的流程由代码预定义；Agent 让模型在受控循环中根据目标、状态和反馈动态选择下一步。Agent 更灵活，也更难评测和治理。
- 为什么很多场景不应该一开始就做 Agent？
Agent 增加成本、延迟、调试难度和安全风险。路径固定、规则清晰、风险高的任务用 Workflow 更稳定。
- 一个 Agent loop 至少包含哪些步骤？
目标输入、状态读取、计划或决策、工具调用、观察结果、状态更新、停止判断、失败处理和 trace 记录。
- 工具 schema 为什么比普通 API 文档更重要？
模型依赖 schema 理解工具用途、参数和限制。schema 不清会导致错误调用、越权、参数缺失和不可恢复失败。
- 工具权限应该如何分级？
可分为只读、草稿写入、需审批写入、高风险执行和禁止访问。权限应由系统校验，不由模型判断。
- Agent 状态和聊天历史有什么区别？
聊天历史是对话记录，状态是可验证、可恢复的任务对象，例如目标、已完成步骤、证据、待审批动作、预算和错误。
- 什么是计划漂移，如何发现？
计划漂移是 Agent 执行中偏离原目标或约束。通过 trace、目标一致性检查、步骤预算、状态校验和轨迹 eval 发现。
- 人类在环审批卡片应该展示哪些信息？
动作、原因、证据、影响范围、风险等级、执行后果、可撤销方式、调用工具、操作者、时间和审计 ID。
- 多 Agent 什么时候值得引入，什么时候是反模式？
职责可清晰分离、任务可并行、需要不同工具或审稿角色时可以引入。简单任务、无合并规则、只为显得高级时是反模式。
- Agent 评测为什么必须看轨迹而不是只看最终答案？
最终答案可能侥幸正确，但中间可能越权、调用错误工具、泄漏数据或浪费成本。轨迹评测能定位控制流和安全问题。