向聊天机器人询问延迟订单的情况，它会给你一些建议。询问 AI 代理，它可以查找订单、检查延迟、申请优惠券并返回报告。不同之处在于，代理可以采取行动并对发生的情况做出反应，而不是只产生一个答复。

该术语在营销中被延伸，因此本指南坚持这些系统的实际工作方式。为了具体起见，我们在 Python 3.13 中构建了一个小型代理循环并运行它，下面的输出来自这些运​​行。 我们的“模型”是一个脚本函数，而不是真正的人工智能模型，因此任何人都可以运行和测试循环。它显示的是控制结构，而不是智能。刚接触基础知识？首先阅读什么是大语言模型。

什么是AI代理？

没有一个统一的定义。在目前的实践中，人工智能代理是一种通过反复决定下一步做什么、使用工具对世界采取行动并根据结果进行调整来追求目标的软件。通常，决策来自大型语言模型。

想一想指路的人和跑腿的人之间的区别。第一个回答一次。第二个出去，发现商店关门了，就尝试另一家，直到工作完成后才回来。

聊天机器人、工作流程还是代理？

这些存在于一个范围内，并且许多有用的系统是混合的。关键问题是有多少路径是在运行时决定的。

代理内部有什么

代理循环

1. 决定。模型查看目标和历史，并选择一个动作或决定它已完成。
2. Act. 您的代码运行所请求的工具。
3. 观察。结果被添加到历史记录中。
4. 重复，直到达到目标或达到限制。

这是大多数代理的核心。复杂性主要在于围绕这个循环的模型、工具和保障措施。

您可以运行的循环

我们的小代理处理延迟订单。它有两种工具，其中一种需要人工批准，因为它需要花钱：

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

这是循环本身。它是普通代码，每个安全规则都位于此处而不是模型中：

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

要使用真实模型，您可以将 model 函数替换为对 LLM API 的调用，并向其传递目标、工具的历史记录和描述。循环几乎保持不变。

我们跑步时发生了什么

我们使用脚本化决策函数尝试了五种情况，并记录了每个步骤。

延迟订单，且凭证已获批准

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

每一步都使用前一步的结果。仅在确认延迟后才考虑使用代金券。

相同的订单，但批准被拒绝

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

人类说不，该工具从未运行，代理调整了其答复。

未知的订单

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

为工具提供清晰的错误消息会有所帮助。真正的模型可以读取它们并做出明智的响应，而不是猜测。

陷入困境的模型

我们还交换了一个错误的决策函数，该函数永远重复相同的操作：

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

代理确实会陷入这样的循环，而真实模型的每一步都需要花钱。如果没有max_steps，这件事永远不会结束。

工具如何工作

这是最容易被误解的部分。语言模型本身无法运行任何东西。它生成结构化文本，说明它想要哪种工具以及什么参数。 您的代码决定是否运行它。这就是为什么循环是权限、验证和日志记录的正确位置的原因。

模型提供者为此提供了工具或函数调用。模型上下文协议 (MCP) 是一种用于将模型连接到工具和数据的开放标准，我们关于 Playwright MCP 的文章展示了一种用途。写下清晰的工具名称和描述，因为模型依赖它们来正确选择。

内存

长任务可能会超出模型的上下文窗口，因此系统通常会总结较旧的步骤。摘要可能会丢失细节，这是长期运行的代理可能偏离路线的原因之一。

多代理系统

一些系统将工作分配给几个专门的代理，例如规划者、研究人员和审阅者。这有助于完成整齐划分的大型任务。它还增加了成本、更多的失败方式和更难的调试。首先尝试使用好的工具的单一代理，只有在有明确原因的情况下才进行拆分。

风险和限制

• 错误的行为。聊天机器人的错误是一个错误的句子。代理的错误可能是发送的电子邮件或删除的记录。
• 提示注入。 代理读取的网页或电子邮件可能包含隐藏指令。将所有工具输出视为不受信任的数据，而不是命令。
• 复合错误。 早期的一个小错误可能会让后面的每一步都走向错误的方向。
• 成本和延迟。每个步骤都可以是另一个模型调用，因此任务可能比单个提示慢得多且成本更高。
• 不一致。同一目标在每次运行中可能采取不同的路径，这使得测试变得更加困难。
• 问责制。 人们仍然对系统的行为负责，因此请保留记录。

护栏很重要

1. 最低权限。 仅向每个代理提供其所需的工具和访问权限。
2. 人类批准任何昂贵的、不可逆转的或外部的事情，就像我们的演示一样。
3. 对步数、时间和支出的硬性限制。
4. 验证代码中的工具输入，并且不依赖于模型指令。
5. 记录每一步，以便您可以了解发生问题的原因。请参阅监控与可观察性。
6. 使用真实场景进行测试， 包括失败。检查最终结果以及个人答复。我们的 AI 代理最佳实践 指南进一步介绍了部署。

何时使用代理

编码助手是当今最成熟的示例之一，因为它们可以读取文件、运行测试、查看失败并重试，并由人工审查结果。测试套件给了他们明确的成功信号。我们的快速工程指南也适用于编写良好的代理指令。从最简单、可行的事情开始，因为经过良好提示的单个呼叫通常会击败复杂的代理。

最后的话

人工智能代理并不像听起来那么神秘：一个模型、一些工具和一个有限制的循环。困难的部分是信任，而不是代码。要了解它们的行为方式，请采用我们的小循环，使用只读工具将其连接到真实模型，并在其工作时观察日志。你很快就会看到它的闪光点以及它需要人类的地方。

常见问题

继续学习