首页  思维导图  详情



 



Agent10 问（总）

2026-08-17 23:22:21   0  举报





AI智能生成

本文件整理了一组以技术面试为线索的 Agent 工程实战问答，核心观点是「接入大模型只是起点，真正的难点在 Harness（驾驭工程）」。内容系统覆盖生产级 Agent 必须解决的五大工程支柱：权限管控、工具编排、错误恢复、上下文管理、审计追踪；并延伸到桌面级 Agent 升级、幂等防重复副作用、检查点续跑、智能重试（指数退避+抖动）、多模型路由（效果/延迟/成本权衡）、企业级 Agent 价值度量（效率/质量/采纳率/ROI），以及腾讯会议后「记录→提取→分配→通知」的自动化编排等真实场景，附带 Agent 项目如何写进简历的实战建议。适合准备 LLM/Agent 应用工程师面试、或正在落地生产级 Agent 系统的开发者参考。

Agent工程

LLM Agent面试

Claude Code

Harness

生产级Agent

模板推荐

作者其他创作

大纲/内容

01、为什么 Agent 最难的不是接入大模型？

真正难的是大模型接进来之后的 Harness

Agent工程化五大挑战

权限管理

Agent 能做什么、不能做什么，必须在权限控制内

最小权限

身份传递

工具编排

Agent 调用的工具越多，工具之间的依赖关系就越复杂

常见问题

哪些工具可以并行执行

哪些必须串行

失败了怎么回滚

超时了怎么处理

错误恢复

常见问题

模型幻觉

超时重试

网络中断

进程挂掉

审计追踪

企业环境里，Agent 做了什么必须可追溯

谁触发的、调了什么工具、传了什么参数、结果是什么，出了问题能回溯

模型路由

能力

延迟

成本

上下文管理

Agent 在长任务中会不断积累对话历史、工具调用结果、中间产物

怎么在有限的窗口里保留最关键的信息，什么时候压缩、什么时候直接扔掉，很影响 Agent 的交付质量

02、用 Agent总结系统文档，怎么判断员工有没有读取权限？

核心就一条——Agent 不能用自己的身份去访问资源，必须用员工的身份

1.身份传递

员工通过登录之后会拿到一个用户令牌（User Token），代表这个员工的身份和权限

Agent需要做一个统一身份管理，所有 Agent 请求都携带这个身份信息

Agent 调用文档的 MCP Server 时，请求里必须带上用户令牌

2.权限验证

MCP Server 收到请求后，拿着用户令牌去文档的权限系统做校验——这个员工对这份文档有没有读取权限

有，返回文档内容

没有，返回权限不足的错误，Agent 告诉员工‘你没有权限查看这份文档’。

3.审计记录

不管校验通过还是失败，这次访问都要记录下来

谁在什么时候尝试读取了哪份文档，结果是什么。

03、终端 Agent 升级成桌面级 Agent 怎么做？

终端 Agent 和桌面 Agent 的五维差异

交互层

命令端

纯文本交互，用户在终端里输入指令，Agent 用文字回复

桌面端

需要 GUI，用户可以点击、拖拽、选择文件、查看图片

交互从单一的文本变成了文本加图形，甚至还有语音

工具层

命令端

核心工具是面向开发场景

读写文件

执行命令

代码搜索

桌面端

系统级工具

剪贴板读写

应用间通信

文件管理器

日历，邮件，

截图

OCR

运行层

命令端

按需启动的，用完就退出

桌面端

作为守护进程常驻后台，随时响应用户唤起

涉及进程管理、资源占用控制、心跳检测这些问题

可见界面

使用场景

命令端

编码

调试

构建

脚本自动化

桌面端

文档处理

数据分析

日程管理

04、如何设计 Agent 的完整审计记录？

审计要记录：谁做的、做了什么、什么时候做的、为什么做、结果是什么

每一条审计记录包含的字段

时间戳

工具名称

工具参数

包含 token，apiKey，密码这些透明信息

写入之前用正则匹配替换掉

不可出现真是密钥，敏感信息

执行结果

通过

拒绝

报错

审批来源

用户手动批准

策略自动允许

执行耗时

存储格式用 JSONL

每条记录是独立的一行 JSON，追加写入

优点

写入性能高，不怕写入中断导致文件损坏

日志按天轮转，文件名带日期

按大小切分。100M/文件

按日期切分。每日一个文件

留存周期 180 天

便于检索，按字段过滤，统计

审计目录的权限

设置成只有当前用户可读写，防止其他进程篡改。

05、Agent 重复调用工具时如何避免重复副作用？

冥等性三层防护

请求层

生成冥等键

每次工具调用生成一个唯一标识，由工具名加关键参数的哈希组成

校验冥等键

执行前先查执行记录，同一个幂等键已经执行成功过，直接返回上次的结果，

重复请求

命中返回旧结果

工具层

upsert

插入或者更新

条件更新

仅满足条件时更新

写文件用覆盖写入而不是追加写入，创建资源前先检查是否已存在

Agent 循环层

循环检测

检测重复调用签名

如果 Agent 连续多轮调用同一个工具、传入相同的参数，说明模型可能陷入了死循环

阈值判断

停滞检测机制

连续 3 轮相同的工具调用会触发退出，避免无意义的重复。

告警通知

记录重复并告警

如何设置冥等键

1.标准化请求参数

提取与业务幂等相关的请求参数并标准化

2.用户或租户标识

识别请求所属的用户编号或租户编号 确保作用域隔离

3.工具名与动作

标识调用的工具或接口名称及具体动作类型 区分不同操作

4.时间窗口

限定幂等键的有效期 包含起始时间与过期时间 避免无限期占用资源

执行流程

参数哈希

将以上要素按固定规则拼接并计算哈希值

去重策略

通过缓存或数据库查询判断

命中 返回旧结果 幂等成功

未命中 执行业务 生成新结果<br>

06、Agent 的长任务如何保证进程重启后继续执行？

靠检查点（Checkpoint）

一个长任务可能包含几十个步骤。任务级恢复，进程挂了整个任务要从头开始

步骤级检查点，每完成一个步骤就把状态写入存储，恢复时从最后一个成功的步骤继续，已完成的步骤不重新执行。

持久化的任务管理模块

用 SQLite 做任务存储

任务的当前状态、输入参数、已完成的步骤、中间结果，都存在 SQLite 里

每个任务有一个状态机

排队中 → 执行中 → 完成或失败

进程启动时，任务管理模块会扫描所有状态为‘执行中’的任务

这些就是上次进程退出时还没跑完的，把它们重新放入执行队列继续

07、Agent 调用模型或工具失败后什么时候可以重试？

可重试错误

HTTP 429 限流

500/502/503/504 服务端错误、

网络超时、连接被重置

临时性故障，过一会儿再试很可能就好了

默认 3 次尝试，退避策略是指数退避加抖动

基础延迟 500 毫秒

每次翻倍，上限 30 秒，再加上正负 20% 的随机抖动

抖动是必须的

如果多个 Agent 同时触发限流，同时等待相同的时间后重试，所有请求就会在同一时刻涌入，又被限流，又等待

抖动让每个 Agent 的重试时间错开，打散请求峰值。

如果服务端返回了 Retry-After，优先用服务端的等待时间

不可重试错误

401 认证失败

400 参数错误

SSL 错误

JSON 解析失败

这些是确定性错误，重试多少次结果都一样

如果模型调用是流式的（SSE），Agent 已经把部分输出展示给用户了，这时候连接断了，不能重试

重试意味着模型重新生成，新的输出和已展示的部分会不一致

流式响应已经有内容被消费了，就标记为不可重试

08、Agent 如何在效果、延迟和成本之间进行模型路由？

先做任务分级，再做模型匹配

简单任务

格式转换、信息提取、短文本摘要

对推理能力要求不高，用快速便宜的模型就够了

复杂任务

代码生成、多步推理、长文档分析

需要强推理能力，用更大尺寸的模型

分级可以用一个轻量级的分类器做，甚至可以用规则

自动路由

第一，前置意图分类器

在主模型调用之前，用一个轻量模型快速判断任务类型和难度。

第二，动态降级

默认用中档模型，如果返回的质量不达标，自动升级到更强的模型重试。反过来，检测到任务很简单，主动降级到便宜模型。

第三，成本监控

按用户、按部门统计 token 消耗和模型调用成本，超出预算自动切换到低成本模型。

也可以手动切换

用户通过命令选择模型，系统在运行时创建新的客户端实例

对话历史保留，上下文管理策略根据新模型的窗口大小自动调整

切换模型时需要注意不同模型的上下文窗口

切换之后，压缩触发的阈值、保留的对话轮数、搜索结果的分块大小都要自动调整。

09、怎么评测一个企业级 Agent 有没有真正创造价值？

效率

真实的使用数据比对

Agent 接手之前，员工完成某个任务需要多长时间？

Agent 接手之后呢？

比如整理一份会议纪要，以前人工要花半小时，现在 Agent 几分钟搞定，就是可量化的效率提升。

质量

Agent 完成的任务准确率怎么样？

有多少需要人工修正？

如果 Agent 总结的会议纪要每次都要改，效率提升就被质量问题抵消了。

采纳率

Agent 上线了，有多少员工在主动用？

用了之后还会继续用吗？

监控指标

日活

周留存

主动调用频率

这些数据能反映 Agent 是不是真的解决了痛点

ROI

Return on Investment，投入产出比

模型调用的成本

MCP Server 的成本

开发迭代的成本

和 Agent 节省的人力成本对比，到底划不划算。

10、设计一个完成的Agent系统

例如

一场腾讯会议结束后，WorkBuddy 需要读取会议记录，提取决策和待办，查询腾讯文档补充背景，把任务分配给对应员工，并在企业微信群里发送通知。请你设计一个完整的 Agent 系统。

这是一个典型的事件驱动+ Agent 编排的系统

腾讯会议结束时发出一个 Webhook 事件，包含会议 ID、参会人列表、会议时长。Agent 编排器监听这个事件，收到后启动工作流

Agent 编排器把整个工作流拆成五个步骤，按依赖关系安排执行顺序

步骤 1，调用腾讯会议的 MCP Server，拿到会议的完整记录，包括转写文本和共享的屏幕截图。

步骤 2，把会议记录交给 LLM，提取决策项和待办事项。每个待办包含内容描述、责任人、截止日期。输出要求是结构化的 JSON。

步骤 3，拿到待办之后去腾讯文档里找相关的背景资料。比如待办里提到‘更新 Q3 预算表’，Agent 需要找到这份预算表的链接，确认责任人有编辑权限。

步骤 4，创建任务，分配给对应的责任人。可以在企业微信里创建。

步骤 5，在会议关联的企业微信群里发送一条汇总通知——会议决策摘要、待办列表、每个待办的责任人和截止日期。

然后是 MCP Server。每个外部系统封装成独立的 MCP Server——腾讯会议的、腾讯文档的、企业微信的。每个 MCP Server 独立部署、独立鉴权，通过 MCP 协议和 Agent 通信。

最后是容错。长流程最怕中断。每个步骤执行完写检查点，失败了从最近的检查点恢复。通知发送失败要有重试。任务创建失败要能降级，保证信息触达。

 Collect

Get Started

CONNECTION AGENT TIE_UP

 Collect

Get Started

问件

 Collect

Get Started

总流程

 Collect

Get Started

Upgrade Agent





0 条评论

下一页