Agent项目面试复盘

我前面几场面试讲项目的时候，一讲出来总有一种“像看过，不像做过”的感觉。
后来自己复盘才发现，问题很多时候不在项目本身，而在于我讲项目的时候太喜欢报菜名了。上来就是用了 RAG、用了 Tool Calling，听起来东西很多，但讲完之后，面试官其实还是不知道你这个项目到底在解决什么问题，你自己又到底做了什么。
3月份的时候我意识到，一个 Agent 项目讲得像不像真的做过，不是提了多少技术词，是有没有把那些只有做过才会在意的东西讲出来。比如不要一上来先讲架构，而是先讲为什么会变成这个架构。
如果只是说“我们用了多 Agent”，这句话其实很空；但如果说“最开始想用单 Agent，后来发现规划、检索和执行全塞在一起之后，链路太长，出错了也不好定位，所以才拆开”，这就一下子不一样了。因为前者是在报结果，后者是在讲你做决策的过程，后者会更像你真的参与过，而不是把一个现成方案复述一遍。
还有一个很重要的点，就是少讲“系统有什么”，多讲“改了什么”。真正会让项目突然变得“像自己做过”的，往往是那些变化。原来怎么做的，后来为什么改，改完之后解决了什么问题，哪个地方当时犹豫过，最后为什么选了现在这个方案。哪怕改动不大，只要是具体的，就会比“做了优化”这种话有说服力得多。
比如说一开始检索结果直接拼上下文，后来发现召回一多模型就会被带偏，所以又补了一层 rerank，把 topk 从 10 压到 5，这种话就很像真的做过，因为里面有问题、有改动。
还有一点我觉得很关键，就是尽量少用那种很抽象的词，多讲动作。比如“做了状态管理”这句话本身没错，但太空了。更像自己做过的说法是，因为这个任务是多步执行的，中间结果后面还要继续用，所以把当前任务状态单独存出来，不然某个 Tool 超时以后很难从中间恢复。只要开始用动作替代名词，整个项目就会一下子真实很多。
我感觉，项目讲得像不像自己真的做过，不是看讲了多少，而是看有没有把这些东西说出来：为什么这么设计，具体改了什么，哪里出过问题，当时怎么处理的，哪些地方现在还不完美，但知道问题在哪。