追问1：你这个项目，到底在解决什么问题？#

很多人介绍项目时，上来就是报菜名式地：

• 接了 tool calling
• 做了 memory
• 支持多轮对话
• 接了 shell / MCP / browser

但你把这些东西列完，面试官其实还是会继续问：

所以你为什么要做这个项目？它到底想解决什么问题？

如果这个点答不清楚，项目就难以有差异度，很容易让面试官感觉：今天这场面试又要听一个 toy project 了。

我觉得一个优秀的思路是，从你自己的痛点出发，带点产品 sense。比如我做的 pico 这个项目，我就会说：

我之所以要自己做个 coding agent，有两点：

1. 可控性。 平时我也会用 Claude Code 这类产品，但很多关键东西对用户来说其实是黑盒，比如 prompt 是怎么拼的、上下文是怎么组装的、工具在什么条件下会被调用，我很难真正判断它为什么这次做对了、下次又为什么会跑偏，某种程度上有点像抽卡。

2. 隐私和部署要求。 实验室有些项目本身有保密约束，不适合直接放到外部开源服务里做，所以我也希望这套 agent 从工具到模型都能自己控制。我在项目里预留了接开源模型的能力，比如可以直接接实验室已经部署好的 Qwen，这样在需要保密的场景下也能真正用起来。

如果有这样的描述，结合自己的痛点，把为什么 + 解决什么问题表达清楚，那面试官对你这个项目的好奇心会多很多。你们会很有话题聊。

追问2：为什么这里要做成 Agent？为什么不直接用现成方案？#

你刚解释完为什么这里要做成 Agent，对方很快就会接着问：

那为什么不是普通 Workflow？为什么不是直接用现成方案？

这类问题一旦被问到，面试官其实就在判断两件事：

1. 你有没有想清楚”为什么这里需要 Agent”
2. 你是不是只是在重复造轮子

因为现在现成方案已经很多了。

你做 code agent，逃不开 Claude Code、OpenCode。你做更通用的 Agent，也很容易被问到 OpenClaw、Hermes 这类系统。

所以你得讲清楚：

• 为什么这里需要模型做动态决策
• 为什么不是固定流程
• 为什么不是直接拿成熟方案来拼
• 你自己做的价值到底在哪

如果你只能回答一句”我想练练手”，这个项目在面试里基本撑不住。

追问3：系统为什么不会失控？#

很多 Agent 项目一开始看起来都挺顺：能对话，能调工具，能跑几轮，甚至还能给面试官演示一下。真正往下问的时候，问题就来了：

• 工具为什么不会乱调
• 状态为什么不会出现偏移
• 上下文为什么不会越堆越乱
• memory 为什么不会把旧信息一直带着跑
• 长任务中间崩了怎么办

很多项目到这里就接不住了。因为大家在做项目的时候最多达到”这个东西跑通过”的程度。但真到面试里，大家更容易挂掉的地方不是它跑没跑通，而是顺着往下问时，你讲不清它为什么没有一路跑偏，为什么还能稳定地跑下去。

追问4：上下文和 memory，到底怎么管？#

上下文和 memory 是每一个 agent 都逃不开的话题，属于是必考的项目问题。

你一上来就说自己做了 memory、做了上下文压缩、做了长期记忆。但面试官真正想了解的是：

• 你到底让它记住了什么
• 什么该进 prompt，什么不该进
• 为什么不是把历史全塞进去
• 旧结论过期了怎么办
• 你的方案是怎么做的，有考虑你的 agent 具体场景吗

面试官不是在听你会不会背术语。他是在看你有没有真正想过：Agent 什么时候该记，什么时候该忘。

追问5：你了解这个方向上已经有什么成熟方案吗？你自己的项目跟它们差在哪？#

不少同学做项目的时候，注意力都放在我把这个东西做出来了。但面试官继续往下问的时候，往往还会在意另一件事：

你做这个项目之前，有没有看过这个方向上已经有什么成熟方案？你自己的项目跟它们差在哪里？

这个问题的难点，不是让你去做一份竞品分析。而是看你有没有基本的判断力和对新技术的敏感度。

比如你做 code agent，面试官很容易问到：

• 你了解过 Claude Code、OpenCode 这些东西吗？
• 你这个项目跟它们相比，差异到底在哪？

如果你做的是更通用的 Agent，也可能会被问到：

• 你有没有看过 OpenClaw、Hermes 这一类方案？
• 你自己的项目重点放在哪？
• 你和这些系统相比，到底少了什么，多了什么，或者你更关注哪一层？

以后大家去实习工作了，一个新项目的落地肯定也逃不过这个问题。你能不能把自己的项目放回到整个生态里去看，面试官就是在提前考察你有没有这样的敏感度。

如果你只会说”我自己做了一个 Agent”，那项目很容易显得视野太窄。但如果你能讲清楚：

• 这个方向上已经有谁在做
• 它们分别强在哪
• 你的项目为什么不跟它们比功能广度
• 你自己这一版重点想讲清楚的到底是哪一层

那会让面试官眼前一亮的。

为什么我觉得 code agent 特别适合校招面试？#

如果要让我推荐一个业务方向，来让项目天然更容易引发面试官继续问，code agent 确实是个很适合讲的垂直方向。

它天然就能把很多面试官会继续深问的东西带出来：

• 工具
• 状态
• 上下文
• memory
• 评测

这些点你只要能讲顺两三层，项目就不只是一个热点词，而更像一个能扛追问的工程项目。也正因为这样，我最后才会选这个方向，自己做了 pico 这个项目。

附：Pico 项目简历描述示例#

Pico: 本地代码智能体 Harness

核心技术： Python、Agent Harness、Tool Calling、Context Engineering、Memory Retrieval、Prompt Cache

项目描述： 面向代码仓库长链路任务开发本地代码 Agent Harness，覆盖模型接入、工具调用、上下文管理、结构化记忆、运行审计与评测闭环，重点解决多轮任务中的上下文膨胀、重复读取、工具误调用和结果不可复现问题

核心工作：

1. Agent Harness 架构设计：负责本地代码 Agent 的整体设计与开发，统一模型接入、工具执行、会话状态和运行工件落盘流程，形成可回放的任务执行链路；支持 2 类模型后端、7 类工具和 3 类运行工件。

2. 长上下文治理：针对代码仓库长链路任务中的 prompt 膨胀问题，设计分层上下文管理与预算裁剪机制；在 12 组真实长上下文配置上，将平均 prompt 长度从 6964 压缩到 5418，平均压缩率 18.01%，最高压缩率 35.63%。

3. 结构化记忆系统：将任务摘要、文件摘要和会话笔记分层管理，并结合 freshness 校验和相关记忆召回减少重复读取；在 12 个真实记忆依赖任务中，将重复读文件次数从 8 次降到 3 次，平均工具步数从 0.67 降到 0.25，任务正确率从 66.7% 提升到 100%。

4. 工具安全与运行治理：构建标准化工具调用与安全边界，覆盖参数校验、工作区隔离、高风险审批、只读委派、重复调用拦截和敏感信息脱敏；在 1 个真实治理场景中，结构化记录 3 次路径选择拦截、5 次无效参数拒绝和 2 次重复调用拦截。

5. 评测与审计闭环：建立固定 benchmark 与运行审计体系，支持 pass_rate / attempts / tool_steps / failure_category / trace 的自动汇总与回归对比；当前覆盖 6 个标准化任务和 86 条自动化测试。

6. 模型后端效果评估：搭建 GPT / Claude provider 分离对比框架，在 GPT 后端的 6 个固定任务上取得 83.33% 的 pass rate，平均 attempts=3.00、平均 tool_steps=2.00，支撑不同模型后端的效果与成本评估。

我想做的，不是一个为了炫技的 Agent demo，是一个真正方便大家拿去研究、包装、写进简历、准备面试的项目。