LLM与AI智能体：通过六个追问追踪一个面试问题

如果询问应聘人工智能工程师职位的候选人LLM与AI智能体有何区别，他们通常首先会回答：LLM负责生成文本，而智能体则能执行操作。面试官很少就此点头然后继续下一题，后续的追问就能看出该候选人究竟有过实际系统开发经验，还是只是背下了定义。以下就是这种对话通常的展开方式，逐题探讨。

LLM自身的功能

语言模型会根据所接收的上下文生成输出，它可以解释错误、总结输入到提示词中的日志或返回结构化数据。但它不能仅凭他人要求就访问私有数据库。因此，当面试官询问人工智能客服助手如何查询实时交易时，答案就是借助工具以及应用代码。

工具的使用方式

想象这样一条客户留言：“我的付款成功了，但订单却没生成。”后端仅提供一些功能有限的接口：

getPaymentStatus(transactionId)
getOrderStatus(transactionId)
createSupportTicket(details)

应用程序会将名称和参数结构与对话内容一起发送，模型可能会回复类似这样的内容：

{
  name: "getPaymentStatus",
  arguments: { transactionId: "txn_123" }
}

面试官的下一个问题是个陷阱：模型刚刚调用了支付服务吗？没有。它只是生成了一个使用工具的结构化请求，目前还没有任何操作执行。

究竟是谁发起调用？

是后端。整个流程实际上包含六个步骤：

1. 应用程序将提示语与工具定义一起发送出去。
2. 模型返回工具名称及参数。
3. 后端检查输入内容以及调用者的权限。
4. 它执行经过审批的函数。
5. 结果作为新的上下文反馈给模型。
6. 模型会请求使用其他工具或给出最终答案。

简而言之，大语言模型负责提出建议，而应用程序则掌控执行、凭证管理及访问控制。这句话值得牢记，因为这是高级面试官会不断追问的要点。

什么让这成为智能体？

在白板上，这个方程很简短：

AI Agent = LLM + Instructions + Tools + State + Execution Loop

智能体监测自身的状态，选择下一步行动，得到结果后再次进行评估，从而形成循环：

Observe → Decide → Request Tool → Execute → Observe Result → Continue or Stop

接下来就是谁来阻止它的问题。模型可以给出最终答案，但应用程序必须设定限制。循环应在达到最大轮数、超时、出现无法修复的错误，或需要人工确认时结束。

同时运行多个工具

这些调用能否同时运行取决于数据之间的依赖关系。支付状态和订单状态只需交易ID，因此两者可以并行获取：

const [payment, order] = await Promise.all([
  getPaymentStatus(transactionId),
  getOrderStatus(transactionId)
]);

现在假设支付响应中包含下一次调用所需的网关引用。那么第二次操作就必须等待第一次操作完成：

const payment = await getPaymentStatus(transactionId);
const gateway = await getGatewayDetails(payment.gatewayRef);

一个出色的回答会表明候选人在并行处理请求之前已确认这些请求是否相互独立。

允许智能体办理退款

正确的回答是，仅凭模型的请求是不够的。后端必须验证交易的所有者——即客户，确认其是否符合条件以及存在哪些限制。写操作需要幂等键和审计日志，而大额退款可能还需要人工审批。系统提示“仅对有效交易办理退款”是为模型提供的指导，并不构成授权。

面试官的评分标准

最初的回答“大语言模型生成响应，智能体执行动作”对于高级职位来说过于简略。它没有说明谁来执行动作、谁拥有相应权限，以及什么机制能防止不安全操作。经过进一步追问后，候选人给出了更完善的答案，但若想从一开始就达到高级职位的标准，最初的回复就应该立即提及应用边界和智能体循环机制。