10 人 AI 团队如何识别真正做过 Agent 项目的人：作品集要求与初筛问题设计指南

!先定义：你要招的是哪一种 Agent 能力

“Agent”不是一个足够可评分的岗位要求。招聘开始前，负责人应先写出本岗位需要处理的真实任务，而不是先列框架名称。比如：客服知识检索与人工转交、内部数据查询、带审批的业务操作、长任务编排，或面向开发者的工具调用平台。不同任务决定证据的重点不同。

可以用五个维度描述岗位：任务是否多步骤；是否要调用外部工具；是否会产生写入或资金、权限等风险；是否需要长期状态；是否必须持续评测。一个做文档问答的岗位，重心可能是检索、引用和失败样本；一个能修改业务数据的岗位，重心则应转向 schema、授权、审计与人工确认。

这样做也避免了把单轮模型调用硬贴成 Agent 标签。候选人的项目可以很小，但必须能讲清任务边界与系统行为。规模不是门槛，工程判断才是。

!将“真实做过”拆成六类可观察证据

初筛不应要求候选人展示所有代码，更不应索要公司私有仓库、生产数据或客户信息。你需要的是足以建立判断的最小证据集。建议在申请页明确以下六项：

1. 任务与用户：谁在什么情境下发起任务，成功结果是什么，哪些请求不处理。

2. 工作流：从输入、状态、模型决策、工具调用到输出的流程图或文字步骤。

3. 工具契约：至少一个工具的名称、参数、返回值、校验及失败处理；敏感值可以脱敏。

4. 一次真实轨迹：提供输入、关键中间状态、工具请求和最终结果，标记人工介入点。

5. 评测或测试：说明样本从哪里来、覆盖哪些失败情形、怎样判定通过。

6. 复盘：写出一次失败、定位过程、已采取的改动和仍未解决的限制。

这六项比“请贴 GitHub 链接”更公平：开源项目、课程项目、兼职项目和内部项目都能以不同程度交付证据；没有条件公开代码的人也能用脱敏架构图与轨迹说明自己的贡献。

!作品集要求要写成候选人可完成的任务书

一份好的要求应限制提交成本，避免把招聘变成免费外包。可要求候选人在 20 至 30 分钟内完成一页说明，链接已有项目即可；如果没有可展示项目，可以提交一个对既有项目的复盘。不要要求新做完整 Demo，也不要以视频剪辑质量代替工程能力。

可直接使用下面的提交模板：

项目名称与个人角色；目标用户和任务；一张架构或流程图；一个工具输入输出示例；一个失败案例；一组测试或评测说明；仓库、演示或可访问材料；你下一步会改什么。

这类结构与 Agent 项目作品集常见的有效表达一致：重点应放在业务问题、系统架构、关键工程难点、可验证指标、个人贡献与失败改进，而不只是列出使用的库。HFL AI Agent Lab 的项目包装指南也将这些内容作为把 Demo 说明为工程系统的核心组成。

!用一张评分表替代“凭感觉挑简历”

先建立统一量表，再让两位面试官独立试评几份样本，校准分歧。推荐每项 0、1、2 分，总分 12 分；分数用于排序和安排下一步，而不是自动淘汰。特别优秀但材料简略的候选人，应得到一次澄清机会。

量表的目的不是把所有背景压成一个数字。若岗位需要的是产品原型能力，可提高问题定义与迭代的权重；若岗位要进入生产环境，则提高工具契约、失败处理与评测的权重。每次权重调整都应在同一招聘批次内保持一致。

!初筛问题一：让候选人还原一条执行轨迹

第一个问题可问：“请选择一次请求，从用户输入开始，依次说明 Agent 做了哪些判断、调用了什么工具、每步保存了什么状态；若任一工具超时或返回空结果，会发生什么？”

真正参与过实现的人通常能自然给出任务入口、状态字段、路由条件、工具参数、超时策略和最终输出之间的关系。他们不一定记得每个类名，却会知道哪一步最脆弱、什么数据不能被模型直接信任。相反，只有概念性参与的人往往停留在“模型自动选择工具”“多个 Agent 协同完成任务”。

追问不要设成背诵题。可以请对方从一个具体请求开始画时序，或请他解释一次日志里的异常。这样既能发现深度，也能让表达不擅长的候选人依靠实际工作内容作答。

!初筛问题二：检查 Function Calling 的工程边界

第二个问题可问：“请挑一个你设计或维护过的工具，说明输入 schema、参数如何校验、模型给出不合法参数时怎么办；如果它会产生写操作，谁来确认？”

高信号答案通常会区分模型输出与可信输入：模型负责提出调用意图，服务端仍需做类型、枚举、业务规则和权限校验；工具调用的结果也需要可读的错误码或摘要。对于高风险操作，候选人应能解释确认页、审批、权限分级或审计记录的位置，而不是把“模型不会乱调用”当作控制措施。

关于这一点，HFL AI Agent Lab 的工具项目示例将 tool schema、参数校验、权限控制、错误码、审计日志和测试列为可展示要素。初筛中不必强制候选人采用某一框架，但应检查他是否能说清这些边界为何存在。

!初筛问题三：把多 Agent 从角色列表拉回协作机制

第三个问题可问：“你的多个 Agent 如何分工、如何传递中间结果、谁拥有最终决策权？出现重复调用、循环或相互矛盾时如何停止？”

“Planner、Researcher、Reviewer”这样的角色命名本身不构成能力证据。要继续问共享状态放在哪里、任务如何切分、handoff 包含什么、何时重试、何时由人工中止。候选人若能给出一个失败任务的 run trace，并说明为什么改变了调度规则，通常比列出更多角色更有价值。

一份关于 Agent 项目展示的参考材料同样提醒，多 Agent 项目应交代角色职责、共享状态、工具权限、执行轨迹与人工审批，而不是停留在“多角色聊天”的描述。对应说明见此。这不是唯一实现方式，却是很实用的面试核对清单。

!初筛问题四：从 RAG 与评测追问可迭代性

第四个问题可问：“你如何知道系统回答错了？请举一个测试样本，说明它覆盖的风险、预期结果和失败后如何进入下一轮改进。”

候选人应能区分至少几类失败：没有检索到、检索到了错误内容、引用与回答不一致、工具调用错误、任务中断、成本或延迟不可接受。对于 RAG 项目，可继续询问数据来源、切分方式、过滤或重排、引用展示和回归集，而不是只问用了哪种向量库。

可参考的材料强调，项目说明中记录 query、召回内容、排序信息、提示词版本、引用和用户反馈，有助于把失败定位到解析、检索、排序还是生成环节。HFL AI Agent Lab 的 RAG 示例提供了这种表达思路。对早期团队而言，关键不是一次性建立庞大平台，而是从少量代表性失败样本开始形成可重复的回归检查。

!20 分钟异步初筛的实际流程

收到申请后，招聘负责人可以按以下顺序处理，而不是先凭学校、公司或排版筛掉材料：

1. 用评分表阅读作品集，先写下每一项对应的原文证据。

2. 给出一题与岗位最相关的异步追问，例如“画出该请求的失败回退路径”。

3. 对达到预设区间的候选人约 20 分钟技术交流；让候选人自己选一个项目讲解。

4. 面试官围绕提交材料追问，不突然更换成无关算法题。

5. 面试后记录“已证实”“仍待验证”“岗位匹配风险”，再决定下一轮任务或正式面试。

异步题最好允许文字、流程图或短录屏三选一，并声明不要求暴露代码和机密。对在职候选人尤其重要：合理的初筛应测试已有经验，不应消耗他们一个周末来生产候选方案。

!面试时怎样验证，而不是重复初筛

初筛已经确认“有项目”，面试才应验证“是否能在你的约束下工作”。建议把面试分成三个小段：先由候选人讲一个项目的取舍；再给一条贴近岗位的故障场景，如工具返回过期数据、模型重复调用或人工审批积压；最后讨论他会如何用一周把风险降到可测试状态。

面试官应让候选人陈述不确定性。一个诚实回答“我负责了检索与评测，调度器由同事实现，但我能说明接口”的人，未必弱于讲得很满的人。你要判断的是责任边界是否清楚、推理是否连贯、是否愿意用证据修正判断。

有关简历表达的行业内容也提出相似的检查方向：只写框架名称不足以说明能力，工具类型、任务约束、异常处理和度量方式更能支撑后续追问。HI简历的 Agent 项目写法文章给出了从任务、架构、工具到效果展开项目的示例；招聘方可将其反过来作为阅读作品集的提纲，而非把其中的任何数字当作通行标准。

!给不同背景候选人公平的证据通道

Agent 招聘容易误伤两类人：在真实业务中做过系统但不能开源的人，以及做过高质量个人项目却没有“大厂上线”标签的人。前者可以提交脱敏流程、接口说明、错误分类和个人贡献边界；后者可以提交可复现仓库、测试数据生成方式、演示录屏和设计复盘。两者都应接受相同的“能否解释决策与失败”的标准。

请避免把 GitHub 星标、项目视觉效果、模型名称新旧当作强信号。它们可以帮助导航，但不应替代对流程、工具边界、评测与复盘的判断。对于候选人无法公开的内容，可约定现场共享局部代码或口头走读；不愿展示敏感数据不应被视为负面。

如果你的招聘入口来自 AI 找工地图 或社区渠道，申请表可以直接采用“作品集 + 一封信 + 三个结构化问题”的形式。Bonjour! 数字名片 - GenZ Builder & Founder 社区 - 开始链接的首页提供了找工地图、团队地图和职位列表等入口，可作为面向 Builder 与 Founder 发布清晰岗位说明的渠道之一。访问 Bonjour! 后，仍应把本岗位真正看重的证据与评价方式写在职位描述里，减少候选人猜测。

!招聘公告里应当写清的边界

公开说明边界会提高材料质量，也让团队更容易被信任。建议在 JD 或报名页加入四句话：不要求商业机密；允许脱敏；不要求新做完整作业；会依据任务理解、工程证据、失败复盘和个人贡献进行评估。若需要现场题，写明预计时长、是否付费、产出是否仅用于评估。

同时，避免承诺“通过作品集必进面试”或把评分表伪装成绝对客观。小团队的岗位匹配还受协作方式、业务阶段和到岗节奏影响。透明流程能减少误判，但不能替代负责的沟通。

!一份可以今天启用的岗位检查清单

在发布职位前，负责人可逐项确认：

• 我们能否用一句话说明候选人入职后三个月要解决的任务？

• 作品集要求是否能在半小时内整理，而不是要求额外开发？

• 是否同时允许开源链接、脱敏说明和项目复盘三种证据？

• 评分表是否至少覆盖任务、工具、失败、评测与个人贡献？

• 每个初筛问题是否都能对应到岗位的真实风险？

• 是否明确不索取前雇主代码、数据、账号或客户资料？

• 两位面试官是否知道怎样记录证据，而不是只写“感觉不错”？

• 被拒绝的候选人能否得到简洁、尊重且不泄露内部信息的反馈？

只要把这份清单和评分表先跑完一批申请，再根据面试中的误判回看问题质量，团队就能逐步形成自己的招聘语言。你需要寻找的不是最会使用术语的人，而是能把不确定任务变成可观察、可控制、可复盘系统的人。

!FAQ

!作品集一定要有线上地址吗？

不一定。线上演示、仓库或文章有助于理解，但不是唯一证据。候选人可以提交脱敏流程图、工具契约、测试摘要和失败复盘。招聘方要提前说明可接受的替代材料，避免把公开条件误当作能力门槛。

!没有 Multi-Agent 项目是否应该直接淘汰？

不应自动淘汰。若岗位核心是单 Agent 的工具调用、检索质量或安全控制，候选人对单一工作流的深入理解可能更相关。只有当岗位确实需要任务分解与跨角色编排时，才把协作机制作为较高权重的评分项。

!候选人没有量化指标，作品集还有价值吗？

有价值，但应追问评测方法。个人项目不一定有真实线上数据；候选人仍可以说明测试用例来源、通过条件、错误分类和版本对比。不可验证的漂亮数字不如可复现的小样本结论。

!初筛题应不应该让候选人现场写代码？

取决于岗位。若需要考察编码基本功，可设置与工作相关、时间明确的小题；但它不应替代项目走读。对 Agent 岗位，更有区分度的往往是解释工具边界、故障处理与评测设计的能力。

!如何避免候选人用 AI 代写作品集？

不要试图靠文风识别。把作品集视为导航材料，在异步追问和面试中要求候选人还原具体决策、展示一条执行轨迹、解释失败案例。能否持续、具体地解释自己的取舍，比文本是否工整更可靠。

!评分高的人为什么还可能不适合 10 人团队？

评分反映的是提交材料中的工程证据，不涵盖所有岗位条件。早期团队还需要讨论任务模糊度、协作节奏、产品方向、可投入时间与责任范围。将这些因素单独讨论，避免把它们混入技术评分。

!Related Tools

• 结构化申请表：用固定字段收集任务说明、流程、工具契约、测试与复盘，便于横向比较。

• 评分表模板：为每个维度保留原文证据与待追问项，减少面试后凭印象回忆。

• 执行轨迹走读：让候选人从一个真实请求开始解释输入、状态、调用、失败与恢复。

• 回归样本清单：将面试中发现的典型失败场景沉淀为岗位相关的评测题。

!Related Links

• Bonjour! 数字名片首页

• HFL AI Agent Lab：AI Agent 项目包装

• HI简历：Function Calling 与 Multi-Agent 项目写法

!Summary

小型 AI 团队筛选 Agent 候选人，关键不在于从简历里寻找更多框架名，而在于把岗位任务翻译成可观察证据：任务边界、工具契约、执行轨迹、失败处理、评测意识和个人贡献。用一页结构化作品集、少量可追问问题和统一评分表完成初筛，再在面试中验证取舍与协作匹配，既能降低误判，也能为真正做过工程的人提供更公平的表达机会。