AI Agent 开发工程师一面面经

1、你这个助手会根据笔记出题。提示词一般包含哪些内容？什么时候会加 few-shot 示例？

我会把任务、材料、约束和输出要求交代清楚。例如根据当前笔记生成五道单选题，每题四个选项、只有一个正确答案，附解析和对应的原文依据。笔记用明确边界与任务指令分开，材料里引用的命令性句子也应作为待处理内容，不直接变成系统要执行的要求。

Few-shot 是在上下文中给少量输入输出示范，适合光靠文字不容易说明的标准，例如什么叫“有迷惑性但不歧义的干扰项”。示例应展示理由，而不只是摆一个 JSON。它不会在这次调用中更新模型权重，主要帮助模型理解当前任务。示例太多会占上下文，也可能让模型模仿相同题型；如果格式说明已经足够清楚，就不必为了使用 few-shot 硬加例子。

2、如果提示词相同，题目还是有时好、有时差，你会直接把 temperature 调到最低吗？它和 top_p 有什么区别？

不会直接认为降低温度就能解决质量问题。Temperature 影响采样前的概率分布：对正温度，通常将 logits 除以温度，再经过 softmax；温度较低时更偏向高分候选。Top_p 则保留按概率排序后累计概率达到阈值的候选集合，再从中采样，控制的是候选范围。

模型最偏好的结果也可能是错的。出题质量波动可能来自材料不足、题目约束不清或示例有偏差，降低随机性不能补齐这些信息。我会固定一批材料，保持其他条件一致，分别比较格式合格率、事实错误和重复题情况。初步调参一次只改一个因素，避免同时改温度、示例和材料后无法判断原因。低温度也不等于跨服务版本严格可复现；参数边界要以所用接口为准。生成与采样说明

3、沿着提示词继续问：笔记、示例和历史对话越来越长，超过上下文限制怎么办？直接截掉最后一部分行不行？

上下文预算要按所用模型的 token 计数，不能用字符数做固定换算。输入不只是笔记，还包括指令、示例、历史消息和工具结果，通常还要为输出留空间。我会先确定这次任务真正依赖哪些信息，再决定保留顺序，而不是从末尾随便截断。

例如用户要求根据第五章出题，当前章节和出题约束应优先保留，早先生成的完整摘要可以移除或缩成任务状态。若单章仍然太长，可以按小节分别生成，再统一检查覆盖范围；但跨小节的综合题需要额外提供相关上下文，不能假设各段模型会自动共享信息。摘要也可能丢失公式前提和否定条件，所以出题时需要的关键原文应保留。这样的处理是控制信息损失，不只是让请求勉强通过长度检查。

4、上下文控制住了，但模型返回的内容偶尔不是合法 JSON。只在提示词里强调“必须返回 JSON”够吗？

提示词是行为要求，不能单独作为程序接口的保证。如果模型和接口支持结构化输出，可以声明对象、必填字段、类型及可表达的约束，让输出遵循指定结构；仍要检查服务是否正常完成，有没有拒绝或被输出上限截断，再进行解析和验证。不同接口支持的 Schema 范围有差异，不能把一家的能力泛化到所有模型。结构化输出及其限制

我会把校验分层：先检查是不是完整 JSON，再检查字段和类型，之后检查业务约束，例如是否恰好五题、答案是否对应某个选项。最后才是内容质量：四个选项都存在，并不代表真的只有一个正确选项。对于可修正的格式错误，可以把具体校验反馈带回去进行有限次数的修正；如果材料不足，应该反馈原因，不能一直重试到得到一个看起来正常的答案。

5、刚才说的是输出结构。Function Calling 的输入参数怎么设计？必填、可选、有默认值是一回事吗？

工具参数要表达操作真正需要的信息。必填表示调用时必须提供这个字段；可选表示允许缺省；默认值则是缺省时采用什么业务值，三者不能混在一起。Schema 中写了一个 default，也不能笼统认为所有校验器或工具框架都会自动填入，应由应用明确实现。字段缺失与显式传 null 也不同，是否接受 null 需要单独定义。

例如扩展一个练习生成工具，可以要求 note_id 必填，把题数设为可选且由服务端默认取五，难度用有限枚举表达，题数再做范围限制。描述里写清单位、用途和缺省行为，比只写几个类型更有帮助。如果用户要求的参数无法满足，应说明冲突，而不是悄悄改掉。模型发出的仍是调用请求，应用检查并执行后才会有真实结果；参数设计不能代替执行与权限检查。工具定义与调用说明

6、调用以后，工具找不到笔记，或者读取服务暂时失败，能统一返回空字符串让模型自己判断吗？

不适合。空字符串可能表示读取成功但笔记为空，也可能表示工具失败；结果含义不清，模型就容易根据已有常识继续编内容。工具返回值应有明确契约，区分成功数据和错误状态，例如使用稳定的错误码、简短说明以及是否适合重试的提示。具体结构按所用框架约定设计，不假设所有工具接口共用一种格式。

比如暂时不可用可以有限重试，笔记不存在则需要重新确认选择，权限错误应停止访问，不能让模型尝试猜其他 ID。程序把内部异常转换成工具可理解的结果时，也应过滤堆栈、凭据等无关细节，诊断信息留在受控日志中。关键是让模型看到足以决定下一步的信息，同时由程序执行明确的重试与权限规则；不能只返回一句“出错了”，然后期待模型猜中原因。

7、如果模型遇到工具错误后不断重复调用，只设置一个最大调用次数够吗？Agent 循环应该怎样结束？

最大次数是兜底边界，还应定义成功、不可恢复失败、等待用户信息和预算耗尽等退出原因。模型通常根据工具结果继续决策，程序则检查这一步是否允许执行、有没有达到停止条件。达到调用上限应返回未完成及原因，不能把“循环停止”当成“任务完成”。

例如连续几次用相同参数读取不存在的笔记，而且没有新信息，就没有必要继续消耗调用额度，应提示重新选择。暂时性的服务失败可以按策略等待重试，所以也不能机械地禁止所有重复调用。除了次数，还可以限制总耗时和输出预算。完成测验的标准由程序检查题目是否合格、保存是否成功，而不是只相信模型说“完成了”。这考察的是循环控制和退出语义，课程项目用清晰的状态判断即可，不需要假装实现了复杂的自主规划平台。

8、那 Agent Skills 解决的又是什么问题？它和刚才的工具、执行流程怎么配合？

工具提供可执行的操作接口；Skill 主要组织完成一类任务所需的说明、脚本和参考资源；工作流负责组织执行步骤。它们可以配合使用。例如“编写单选测验”技能说明怎样设计干扰项、怎样引用依据，执行中可以使用笔记读取工具，最后仍由程序验证后保存。写了技能并不意味着它自动拥有工具权限，也不等于工作流会严格按说明执行。

Agent Skills 常用 SKILL.md 和配套资源目录承载这些内容，按需逐步加载：先利用名称和描述判断是否相关，再读取完整说明，最后读取实际需要的参考资料。相比把全部规则放进每次提示词，这有助于控制上下文占用；但描述不清时也可能选错技能，需要用任务样本验证。Agent Skills 官方说明

在这个课程项目中它属于扩展思路：等出题和卡片生成形成稳定的不同规则后再考虑拆分。近期可核实的进展是 Anthropic 于2026年10月22日公告将该开放标准捐赠给 AAIF；这里关注的是规则复用方式，不要求把发布新闻当八股背诵。官方公告

9、换到实现层面：模型请求经常在等待网络响应，Python 的 async/await 为什么适合这种任务？把函数改成 async def 就一定不会阻塞吗？

异步适合等待较多的 I/O 任务。协程等待一个尚未完成的异步操作时，可以让事件循环去推进其他就绪任务，不必让整个线程只等这一份响应。它主要改善多个任务等待时间的利用，不会让单次模型计算自动变快，也不等于多个 Python 计算任务在一个线程中同时执行。

只写 async def 并不够。如果里面仍调用同步 HTTP 请求、time.sleep 或长时间运行纯计算，事件循环还是会被占住。模型调用应使用支持异步等待的客户端；不得不调用阻塞 I/O 时，可以考虑线程执行，并检查客户端的线程使用约束。CPU 密集任务则要另选适合的进程或计算服务。判断一个接口是否真正异步，要看执行过程能否在等待处让出控制，而不只是看函数声明。Python 协程与任务

10、如果用户同时要摘要和知识卡片，连续写 await summary()、await cards()，它们会并发吗？

如果这里调用的是两个协程函数，直接先 await 第一个、再 await 第二个，仍是顺序执行：第二个要等第一个结束才开始。对于互不依赖的操作，可以先创建任务，或用 asyncio.gather 等方式并发等待。假设两次请求分别耗时两秒、三秒，且没有共享瓶颈和其他开销，串行约五秒，并发约三秒；这只是解释调度的理想算例。

是否独立要看数据依赖。摘要与卡片如果都直接基于已经读出的笔记，就可以分别开始；如果卡片要求从摘要中提炼，就必须等摘要完成。也不要为了并发让两个任务随意修改同一个结果字典，可以各自返回结果，再统一组装。返回顺序与完成顺序也不同：gather 的结果按传入顺序排列，不代表第一个请求先完成。

11、任务变多以后，全部交给 gather 就可以了吗？如果其中一个失败，其他任务会怎样？

并发数量需要受控。一次发出很多模型请求可能触发服务限流，也会占用本地连接和内存。Semaphore 可以限制同时进入某段调用代码的任务数量；它控制的是在途并发，不等于每秒请求数限制，所以仍需根据服务的限流规则处理拒绝和等待。这个课程项目先设一个较小并发上限即可，不需要一开始就引入复杂调度系统。Python 信号量

gather 默认在某个任务抛出异常后把异常传播给等待者，但不会因此自动取消其余任务，不能误以为“捕获异常就代表整批都停了”。如果任务相互独立，希望成功的结果保留下来，可以使用 return_exceptions=True 收集各项结果与异常；如果要求整组失败时停止其他任务，则需要不同的取消策略。失败行为应先按业务确定，再选并发 API。

12、按你刚才的思路，写个小函数：批量处理笔记，最多三个调用同时执行，结果按输入顺序返回，单项失败不影响其他项。

这里假设 call_model 是一个异步函数，每项任务彼此独立，输入规模较小。用信号量包住真正的模型调用，gather 负责按输入顺序收集结果。为了便于单独测试，将并发上限写成参数，默认值为三。

import asyncio

async def generate_batch(notes, call_model, limit=3):
    if type(limit) is not int or limit < 1:
        raise ValueError("limit must be a positive integer")
    semaphore = asyncio.Semaphore(limit)

    async def run_one(note):
        async with semaphore:
            return await call_model(note)

    return await asyncio.gather(
        *(run_one(note) for note in notes),
        return_exceptions=True,
    )

返回列表的每一项是成功结果或异常对象，调用方需要逐项识别，不能直接把异常当正常内容存入数据库，也不能原样当 JSON 发给前端。若外部取消了整个批次，gather 会向未完成任务传播取消，不把用户取消当作普通的单项失败吞掉。实际请求还应设置超时，避免某项永久等待。

这段代码一次创建全部等待任务，只限制活跃调用数；几条到几十条的演示批次适用，如果输入极多，应改成有界队列加固定数量的工作协程。验证时除了看返回值，还要记录测试桩的最大同时执行数，确认不超过三，并故意让先输入的任务后完成，检验结果顺序没有被打乱。