探讨为何AI答案中提到的品牌常被Agent跳过——工具缺少机器可读的权限声明和输入输出schema。提出用capability manifest暴露工具能力、权限、返回格式和失败报告方式。
AI agent optimization 弥合了"在答案中被引用"与"被选中执行操作"之间的鸿沟。
OpenAI 2026 年 8 月 7 日的报告称,职场用户使用 ChatGPT 进行补全或创作的可能性是职场外用户的两倍以上。然而约 49% 的查询仍属于"提问"类。在答案层之上,执行层因此加入——但它并不取代答案层。
一个品牌可以出现在 AI 生成的答案中,却可能在用户委托下一步操作时被跳过。Agent 可能理解该品牌的专业知识,却没有找到它能安全调用的能力。
对工程师而言,需求是具体的:暴露工具做什么、接受什么输入、需要什么权限、返回什么、如何报告失败。
能力清单(capability manifest)可以使这些细节在调用前即可被检查:
{
"name": "create_content_brief",
"description": "Create a content brief for a topic and audience",
"input_schema": {
"type": "object",
"required": ["topic", "audience"],
"properties": {
"topic": { "type": "string" },
"audience": { "type": "string" }
}
},
"permissions": {
"read": ["approved_sources"],
"write": []
},
"result_schema": {
"status": ["completed", "failed"],
"data": "object_or_null",
"error": "object_or_null"
}
}
具体协议可以有所不同,但 Agent 不应从营销文案中推断所需的输入、权限或失败行为。
针对每个能力进行五项检查:
Discoverable:它的描述能否将用户意图与具体操作连接起来?
Callable:必需的输入是否结构化且明确?
Reliable:返回的形状是否足够一致,能供下一步工作流使用?
Bounded:它是否只请求该操作所需的访问权限?
Safe:它能否在无法提供完整结果时报告失败,而不会将不完整结果当作成功返回?
回答"这是什么?"的页面与处理"用它完成任务"的能力服务的是不同意图。支持委托工作不意味着移除解释性内容。保留答案层,然后在旁边添加执行层。
这一区分很重要,因为仅靠可发现性可能赢得提及(mention)而不一定能赢得选中(selection)。仅靠可调用性可能将失败推迟到执行阶段。安全使用 Agent 需要从意图到结果的完整路径。
记录每个候选能力的选择决策,包括能力被考虑但未选中(considered but not selected)的情况:
{
"timestamp": "timestamp",
"request_id": "request_identifier",
"capability": "create_content_brief",
"eligible": true,
"selected": true,
"execution_status": "completed",
"fallback_used": false,
"failure_code": null
}
这支持可操作的指标:
Agent Selection Rate:被选中的候选请求数除以所有候选请求数。
Completion Rate:完成的执行数除以选中的执行数。
Fallback Rate:使用降级方案(fallback)的执行数除以选中的执行数。
如果只记录成功调用,就无法看出能力是在选择阶段被跳过还是在执行开始后被放弃。
宽泛的承诺看起来可能具有可发现性,却让输入、权限和输出变得模糊。更窄的能力则更容易评估、调用、监控和安全失败。
持久的方法是叠加式的:持续优化答案的内容,然后为 Agent 提供一条结构化、可衡量的行动路径。
在当前技术栈中,Agent 交接环节最难的部分是:能力发现、结构化输入、权限边界、完成追踪,还是降级行为?
📖 Read the full guide → AI Agent Optimization: From Asking to Doing
For further actions, you may consider blocking this person and/or reporting abuse