LLM 的交互方式有所不同。LLM 不只是根据模式检查数据，它还会读取关于工具或其他系统能做什么的纯语言描述。作为开发人员，我必须公开调用 LLM 可以读取、使用并最终用于理解如何操作我的界面的信息。你不能给 LLM 一个严格的模式。相反，你需要提供一份描述，包括工具的目的、输入和预期结果。
LLM 利用其语言理解能力，根据描述找出工具的使用方法。这就好比从检查死板的表格到理解口头指令。这种方法更加灵活，尤其是对于结构化程度较低的任务，但这也意味着交互取决于解释，而解释的可预测性可能不如严格的格式。从模型上下文协议（MCP）到我在上一篇博客中提到的谷歌开源代理开发工具包，你可以看到这种方法被广泛应用。
提示是新的 "应用程序接口文档"
因此，对于 LLM 而言，"API 合同 "或文档实质上就是你为描述工具或功能而编写的提示。现在，开发人员不再编写代码注释或模式文件，而是编写清晰、详细的说明，告诉 LLM：
- 它的作用：该工具的主要功能。
- 需要什么？所需的输入内容，或许可以提供示例或格式提示。
- 它的回报：预期产出或行动。
- 任何规则：重要限制或指导原则。
这意味着提示工程正成为一项关键技能。要使这些系统正常运行，开发团队必须能够编写 LLM 能够可靠理解和执行的指令。
简单示例：法学硕士的 "日历助手 "工具
让我们想象一个更有活力的工具，比如日历助手，并为法律硕士描述一下：
整体工具描述："这是一款日历助理工具。它可以为一组人安排新的会议，并查找可用的时间段"。
功能 1：创建会议 提示： 工具名称： CreateMeeting.说明在日历中安排新会议。所需输入： attendees (电子邮件地址列表）、 subject (会议标题）、 startTime (会议开始的日期和时间；尽量解释相对时间，如 "明天下午 3 点 "或 "下周一上午"），以及 duration (描述时长的文本，如 "1 小时"、"30 分钟"）。可选输入：地点（文本，如 "B 会议室 "或视频通话链接）。如果调度失败（如时间冲突、无效与会者），系统会回复一条确认信息，其中包括最终会议细节或错误信息。如果开始时间或持续时间不明确，请在继续之前向用户询问清楚。除非另有说明，否则假定时间为用户所在时区的时间。
法律硕士可能如何使用它（在解释用户请求之后）： 创建会议（与会者=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")
函数 2：查找空闲时间 提示： 工具名称： FindFreeTime.描述为一组人查找指定时间段内的常用空闲时段。所需输入： attendees (电子邮件地址列表）和 duration (描述所需会议长度的文本，如 "1 小时"）。可选输入： timeWindow (文本，例如 "下周"、"本周五下午"、"未来 3 天内"；如果未指定，默认为当前工作周）。回复可用的开始时间列表（日期和时间）或提示未找到常用时段的信息。如果使用 "下周 "这样的相对窗口，则应具体说明搜索的日期范围。除非另有说明，否则假定时间为用户所在时区的时间。
法律硕士可能如何使用它（在解释用户请求之后）： FindFreeTime(attendees=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")
在这里，提示会指导 LLM 如何处理列表、解释日期和工期等可能模糊的输入，甚至何时要求澄清。这更接近真实世界中 LLM 工具的交互方式。
挑战：模糊性和及时性（为本系列第三部分做好铺垫）
作为开发人员，第一次创建这样的工具时，你会想'这太神奇了！编写这些代理程序简直易如反掌"。然后，就像开发人员生活中经常发生的那样，现实给了你当头一棒...
虽然日历助手的提示会尝试处理一些模糊的问题（如 "明天下午 3 点"），但依靠自然语言描述可以为软件带来新的令人兴奋的方法，让它做出一些你意想不到的事情。
请看这些例子：
- 创建会议请求冲突：
- 用户："本周五下午为我和查理预约一次 2 小时的会面，但一定要在下午 2 点之前。
- 问题："星期五下午 "通常意味着 12 点或下午 1 点以后。而 "下午 2 点前 "则会产生潜在冲突或非常狭窄的时间窗口（如下午 1 点到 2 点）。提示并没有明确告诉 LLM 如何处理时间等单一参数中的冲突约束。它应该优先处理 "下午 "还是 "下午 2 点之前"？是否应该向用户展示冲突？
- 模糊的查找自由时间请求：
- 用户："下周找时间和戴夫聊一聊"。
- 问题：什么是 "快速聊天"？持续时间参数需要更具体的内容，如 "15 分钟 "或 "30 分钟"。当前的提示需要一个持续时间，但没有指定默认值，也没有说明如何处理 "快速聊天 "这样的模糊术语。LLM 可能会失败或不得不猜测。
- FindFreeTime 中的隐含假设：
- 用户："为下周三的团队会议找一个小时的时间"。
- 问题：谁是 "团队"？本地语言管理器需要与会者名单（电子邮件地址）。提示需要这个，但用户请求依赖于本地语言管理器知道 "团队 "的上下文。如果没有提供与会者名单或无法从通话记录中推断出与会者名单，那么一个好的交互流程可能会让本地语言管理器询问 "谁是团队成员？在这种情况下，主叫代理可能会呼叫另一个代理来了解谁是 "团队 "成员。
- 未指定时区：
- 用户（伦敦）："安排明天上午 9 点与 Priya（纽约）会面"。
- 问题：是伦敦时间上午 9 点还是纽约时间上午 9 点？当前的提示包括一个基本假设（"除非另有说明，否则假定时间为用户所在时区的时间"），但正确处理时区问题非常复杂。如果用户没有指定，而与会者又在不同的时区，该怎么办？工具需要复杂的后台逻辑来处理时区，或者在提示中提供更明确的指示，说明如果涉及多个地点，如何请求和确认时区信息。简单的假设可能会导致日程安排错误。
这些例子表明，即使有很好的提示，用户请求中的含糊不清、相互冲突的信息或未说明的假设（如时区）也可能导致错误、不正确的操作或令人沮丧的澄清循环。LLM-API 交互的有效性直接取决于描述工具功能和限制的提示的质量和完整性。它不仅需要涵盖正确的路径，还需要涵盖如何处理模糊信息、缺失信息、潜在冲突以及时区等背景细节。
越来越复杂：当多个人工智能代理对话时（过渡到更深层次的问题）
准确描述单个工具是一回事，但当多个人工智能代理试图协同工作时，情况就变得棘手多了。如何编写提示，让代理 A 清楚地了解代理 B 能做什么、不能做什么，包括代理 B 如何处理模棱两可的问题？它们如何协调？如何确保它们可靠地协同工作，而不会因为如何解释彼此的指令而出现意外问题？随着这些系统的发展，我们面临的一大挑战就是如何用语言清晰可靠地定义这些交互。
了解Akamai如何大规模支持您的人工智能工作负载。立即与我们的专家联系。
注释