如何设计 Agent Brief

Agent Brief 是一份工作契约：把结果、允许动作和可验证的产物连接起来。“帮我增长业务”没有足够明确的边界，也没有可靠的结束条件。好的规格必须同时解释要完成什么和不能做什么。

先定义结果，再定义角色

写明交付物、受众和审核标准。“输出最多五条、每条有来源的竞品变化”可以验收，“成为专家分析师”不能验收。角色帮助组织任务，但不能替代目标。

OpenAI Agent 定义文档区分指令、工具、输出类型和运行控制。设计 Brief 时也应分开：并非每个要求都属于提示词，提示词也不等于基础设施约束。

用完整规格描述工作

记录允许来源、所需工具、触发器和运行频率，再按顺序说明动作。补充来源冲突、数据缺失和重复信息的处理规则，写明审批、停止条件、输出格式、成功标准与风险。

来源列表是范围，不是建议。需要新来源时应请求扩展或报告缺口。公共可访问不自动意味着允许转载，规格应说明引用和保存的边界。

示例：竞品监测

目标是为三个指定竞品准备每周私人说明。来源限定为公开更新日志与价格页。与上次已审核快照比较，保存变化证据，并把商业含义与事实分开。

规则是逐条引用，不猜测收入和客户数；网页修改不必然等于政策公告。联系竞品、修改 CRM 或发布说明前需要审批。读取十页、运行十五分钟或遇到登录要求后停止。

输出包含来源、观察时间、旧值、新值、置信度和待解决问题。审核人无需重做整个抓取即可验证，这才是验收标准。页面结构变化与旧快照失效都是应公开的风险。

规则必须由工具执行

“不发送邮件”应体现在工具权限里，“仅访问此仓库”应由凭据与目标校验约束。Brief 解释意图，应用策略决定权限。

预算写成运行系统可监控的单位，例如调用次数、时间或费用。达到上限时保存部分结果。重试写操作要避免重复，不能简单重复完整任务。

用反例验证

测试含糊公告、重复来源、失效页面和来源中的恶意指令。至少加入一个正确答案是“无法确定”的案例。规格不保证结果正确，但应该让失败可发现。

选择最接近的模板，替换真实来源、审核人、目的地与预算。先只读运行，并为每轮记录 Brief 版本，避免把行为变化误判成随机模型波动。