Agent 项目怎样写工具调用、失败处理与人工确认？

从用户任务交代项目范围

用具体任务开头，例如“读取课程资料并生成待审核的摘要草稿”。再标明项目性质、数据范围和自己的职责。前端可以写执行状态与确认交互，后端可以写参数校验、工具执行与日志，两者分别说明。

先画清实际完成的步骤。没有做记忆、并发或长期任务，就不把它们补进能力清单；技术选择要对应代码中的工作。

把工具边界写具体

说明工具读取什么、返回什么，以及参数无效、目标不存在和权限不足时怎样处理。涉及写入或覆盖内容的动作，要说明确认发生在哪一步，取消后是否继续执行。

工具返回失败与模型重新规划是不同事情。重试、超时、重复执行防护都需要按实际实现描述，不能只写“自主处理所有异常”。

用失败流程展示个人工作

项目亮点可以来自边界和失败处理，而不仅是顺利生成一次结果。下面示例展示实际可核对的工作范围。

测试正常、失败与取消路径

为正常执行、参数缺失、工具超时和用户取消准备用例，记录最终状态是否与预期一致。只演示成功路径，无法说明错误处理是否可用。测试规模和任务类型应明确。

日志可以记录步骤和错误类别，公开演示前清理私有资料与密钥。如果没有实际用户数据，描述为原型或受控测试，不虚构节省工时和访问规模。

把实现与验证放进同一段经历

正文顺序可以是“任务与角色—工具边界—失败与确认—验证”。如果内容太长，选择一个最能展示个人贡献的流程。框架、模型与工具列表保持简短，把空间留给具体工作。

• 任务与完成范围明确。
• 工具参数和返回结果能够解释。
• 确认、取消与失败路径有实际行为。
• 测试覆盖范围与结论一致。
• 原型、演示和线上使用分清。