后端转 Agent 岗最常见的错位是这一种：简历里 Agent 内容只有两三行，面试里被问的全是后端题。
不是面试官不懂 Agent，是他手上只有你的简历。问题分布基本等于简历的项目权重分布。
这句话反过来用就是方法：你想被问什么，就在那上面堆出足够的问题密度。下面按技术密度讲四件事：项目要补哪些可追问的结构，记忆为什么要外置，工具链路怎么拆，MCP 的边界怎么划。后面另外补三处简历硬伤和一段 AI 协作方法。
一、先承认这个映射关系
一个典型的简历长这样：四个项目里三个是后端项目，唯一的 Agent 项目正文两三行。我见过好几份长这样的简历，结果都差不多，几乎没问到 Agent。
原因很直接。两三行最多够问一轮，剩下的时间面试官要么放你走，要么回头问后端，因为那里的素材足够撑满整场。
反过来看面试官视角的提问成本：
这张表不是精确统计，是个判断模型。它的用处是让你在投简历之前先自查一件事：你想被问的那个方向，在简历上的篇幅占比是多少。
二、Agent 项目要补的四个抓手
功能数量不影响面试官判断，能不能插进去提问才影响。四个抓手，按这个顺序补最省力。
意图识别。用户说一句话，你怎么知道他要干什么。直接把这句话丢给模型不叫意图识别，那叫转发。真做过的版本能回答三件事：怎么分类，分类不准怎么澄清，完全认不出来怎么兜底。
Agent 生命周期。一次会话从进入到结束，中间有哪些状态，谁负责推进，超时怎么办，用户中途改主意怎么办。状态讲得清，面试官会认为你写过生产代码。
记忆分层。这一处最容易被问穿，下一节单独说。
工具调用链路。这一处有固定模板，再下一节单独说。
三、记忆分层：为什么长期信息必须外置
最容易被问穿的错误答法是「我们有记忆机制，能把用户历史信息记住」。往下问一句存在哪，就卡住了。
从工程角度看，把长期信息塞进 context 有两个成本绕不开。
第一个是 token 成本。上下文随轮次线性增长，历史越长每次请求越贵，而且这部分钱花在重复传输上，不产生新信息。
第二个是注意力稀释。上下文里塞进大量与当前问题无关的历史，模型对关键指令的注意力会被摊薄，表现不是报错，是回答变得含糊。
还有一致性这块，吃过亏的才知道：偏好类信息散落在多轮对话里，没有单一事实来源，同一个用户下次换个会话再问，行为就不一致。
所以正确口径只有一条边界：短期记忆是当前这次对话的上下文，存在会话里，跟着这次请求走；偏长期的信息，比如用户偏好、历史行为，不该塞进 context，而是去调外部服务，比如公司内部的用户画像服务。
伪代码大致是这样：
# 伪代码，示意分层职责，不是可运行实现
def build_context(session, user_id, query):
# 短期：只取最近若干轮，超出就滚动丢弃
recent = session.tail_turns(n=RECENT_LIMIT)
# 长期：不拼进 prompt，按需查询，只取当前意图相关的字段
profile = profile_service.get(user_id, fields=relevant_fields(query))
return compose(
system=SYSTEM_PROMPT_SLIM,
long_term_hint=profile.as_hint(), # 只放结论，不放原始流水
recent_turns=recent,
query=query,
)
这段伪代码里真正值得讲给面试官听的是两处：tail_turns(n=RECENT_LIMIT) 说明短期有上限，profile_service.get(...) 说明长期信息走外部服务而不是拼字符串。剩下的是实现细节。
四、工具调用链路：四段拆法
任何自研工具都能套同一个模板：输入从哪来，中间怎么处理，输出给谁，异常怎么兜。
以一个批量入库工具为例，四段拆开是这样：
工具的 schema 也要能说清，因为模型是靠这个描述决定调不调：
{
"name": "import_batch_rows",
"description": "按批导入行数据，返回成功条数与失败行",
"parameters": {
"type": "object",
"properties": {
"file_url": { "type": "string", "description": "待导入文件的地址" },
"batch_size": { "type": "integer", "description": "单批行数，不传则用默认值" },
"retry_failed_only": { "type": "boolean", "description": "是否只重试上次失败的行" }
},
"required": ["file_url"]
}
}
这里的做法是只把兜底参数设为必填：批大小和重试开关都能被默认值兜住，文件地址拿不到就没什么可执行的。这种设计细节比功能列表有用得多，因为它说明你考虑过参数缺失的分支。
很多人讲工具习惯从技术栈讲起，用了什么框架，接了什么模型。技术栈是结果不是链路。面试官想听的是数据怎么流动，以及出问题的时候你在哪一层兜住。
五、MCP：模型决策，运行时执行
这一处最容易自己给自己挖坑。
如果 MCP 工具是模型自己决定调用、由运行时去执行，正确的说法只有八个字：模型决策，运行时执行。不要说成「我实现了协议调用」。
两者的追问深度差一个数量级：
你把边界说在哪一层，就要准备好那一层的追问。说成自己实现的协议，等于邀请对方考协议细节，问到规范层就当场崩。
面试里最贵的不是不够高级，是高级了但接不住追问。一句撑不住的高话，比一句实话伤害大得多。
同样的判断标准可以套到所有表述上：这句话出去，对方追问三层，你能不能接住。接不住就降一层说。降一层不掉分，接不住才掉分。
六、简历层面还有三处硬伤
第一处是两个项目都写「至今」。面试官会算你的并行度和在职时长，两个至今放在一起逻辑上不成立，等于主动邀请他怀疑真实性。改法是说清哪个是主线、哪个是并行的副线，时间区间各自落到月份。空档可以解释，逻辑矛盾解释不了。
第二处是项目顺序。把想被问的项目放在最前面，因为面试官的注意力也是有限资源，第一屏决定他先问什么。这一条是我自己加的判断，不在这次复盘里。
第三处是项目取舍。四个项目要不要删，判断是不用全删，重点扩核心；真要删，删相关性最低的那个。判断哪个该删需要两个条件同时成立：与目标岗位相关度最低，而且你自己讲不出三个细节。保留一个讲不动的后端项目，比删掉它更伤，因为讲不动的地方就是减分的地方。
七、顺带说 AI 协作开发：分工与校验
这套跟面试技巧无关，但它决定你手上有没有真项目可讲。
定位是：用 AI 的时候，把 AI 当员工，你自己是老板。
按能力边界分活，别让一个模型干所有事：
最后一行值得展开。开发和测试用同一个厂商的模型，两边会对同一类错误同时失明，测试就变成了自我确认。跨厂商选型的价值不在谁更强，在于错误模式不重合。
三条文档原则：先用技术文档约束 AI 的输出，而不是让它先写代码；文档和代码一起进代码库，文档不是写完就丢；测试驱动，先让 AI 生成测试用例再让它写实现。
重复动作要 Skill 化，比如自动生成提交信息、线上问题排查、代码检索。Skill 会不会被正确调用，靠三件事校验：约定场景的触发关键词、看模型的执行过程、任务结束后让模型自己复核这次工具调用是否合理。
还有三件踩过坑才知道的：AI 跑长任务卡住或超时，主动打断问进度、补信息，别干等；上下文要主动压缩，把历史对话总结成文档，新开窗口再读回来；多窗口要分工，架构师一个窗口、并行开发几个窗口、代码审查一个窗口，按垂直解耦的需求拆才能真并行。
结语
回到开头那个映射关系。面试官的问题分布等于简历的项目权重分布，这不是玄学，是信息不对称下的必然结果。
所以转岗的动作不是「在简历里加一行 Agent」，而是把那个项目扩到能撑住三轮追问：第一轮问你怎么做的，第二轮问为什么这么做，第三轮问出问题怎么办。
三轮撑得住，方向对了；撑不住，功能再多也还是那两三行。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
The most common error in the back-end turnover of Agent is this: Agent has only two or three lines in the curriculum vitae, and all the questions in the interview are back end.
Not that interviewer doesn't understand Agent. He only has your resume. The distribution of problems is essentially equal to the distribution of project weights in the curriculum vitae.
And that, in turn, is the way: if you want to be asked what you want to be asked, you have to pile it with enough problem density. Here's four things by technology density: what can be asked about the structure to be added to the project, why the memory should be replaced, how the tool chain should be broken, and how the MCP's borders should be drawn. Three additional CV injuries and an AI collaborative approach were added.
First, admit the map.
A typical curriculum vitae follows: three of the four projects are back-end projects, and the only Agent project consists of two or three lines in the main text. I've seen several of these long résumés, and the results are similar, almost without asking Agent.
The reason is direct. Two or three rows can last up to one round, and the interviewer will either let you go or go back to the back end, because asset there is enough for the whole scene.
The cost of looking at the interviewer's perspective in turn:
This table is not accurate, it's a judgement model. It's useful for you to look at one thing before you throw your curriculum vitae: the direction you want to be asked, the size of the curriculum vitae.
Two, four catchers for the Agent project.
The number of functions does not affect the opinion of the interviewer, but rather the ability to insert questions. The four grabs, in that order, make up the least effort.
Intentional recognition. Users say one thing, how do you know what he's doing? It's not meant to be identified. It's referred to as forwarding. The version that really did answer three things: how to classify, how not to clarify the classification, how not to know the bottom.
Agent life cycle. What about the status of a session from entry to completion, who's in charge of pushing, what about timeout, and what about the user's change of mind. The interviewer will think you wrote the code.
Memory layers. This is the easiest place to be asked about, and the next section is separate.
tool call link. This section has a fixed template, which is discussed separately in the next section.
Memory layers: why long-term information has to be externalized
"We have memory mechanisms to remember user history." If you ask me where it is, it's stuck.
From a engineering point of view, there are two costs involved in putting long-term information into context.
The first is token costs. The longer context grows along the wheel line, the more expensive it is every time it is requested, and the money is spent on repeated transmissions without generating new information.
The second is the dilution of attention. context is stuck in a vast amount of history unrelated to the current problem, and the model ' s attention to key commands is diluted, not misperformed, but vaguely answered.
There is also the element of consistency, which is known only to those who suffer: there is no single source of information for the preferred categories in multiple rounds of conversations, and the behaviour of the same user is not consistent with the next time the same user is asked in another session.
So the correct calibre has only one boundary: short-term memory is the context of the current dialogue, which exists in the conversation and follows this request; long-term information, such as user preferences, historical behavior, should not be put in contact, but outside services, such as intra-corporate user image services.
Hypocrisy code is about the following:
# Hypocrite, indicative layers of responsibility, not operational
def build_context(session, user_id, query):
# Short-term: take only the latest rounds and roll over and discard them
recent = session.tail_turns(n=RECENT_LIMIT)
# Long-term: do not spell prompt, search as needed, only field on current intent
profile = profile_service.get(user_id, fields=relevant_fields(query))
return compose(
system=SYSTEM_PROMPT_SLIM,
long term hint=profile.as hint(), # Only conclusions, no raw water
recent_turns=recent,
query=query,
)
This fake code is really worth talking to interviewers in two places: tail turns (n=RECENT LIMIT) indicates short-term ceiling, profile service.get(...) indicates long-term information going outside rather than spell strings. The rest is for details.
IV. tool call link: four segments of dismantling
Any self-study tool can fit the same template: where the input comes from, how it's handled in the middle, to whom it's exported, how it goes.
In the case of a batch-entry tool, for example, four segments were opened:
The schema of the tool also needs to be clear, because the model is based on this description:
{
"name": "import_batch_rows",
"Description": "Cast import line data, return successful bars and failed lines",
"parameters": {
"type": "object",
"properties": {
"file url":
"Batch size": {" type": "integer" and "description": "The number of single rows, the default value if not passed"},
"retry failed only" : {"type": "boolean", "description" : "Is it just retry's last failed line"}
},
"required": ["file_url"]
}
}
The practice here is to set only the bottom parameters to be filled: batch size and retry switches can be covered by default, and there is nothing to execute without a file address. This design detail is much more useful than the functional list because it indicates that you have considered the branches of missing parameters.
A lot of people talk about tool habits from the technology vault, what framework, what models they take. The technology vault is the result, not the link. The interviewer wanted to hear about how the data flowed and what floor you were on when it went wrong.
MCP: Model decision-making, operational implementation
This place is the easiest place to dig for itself.
If the MCP tool is the model's own call and is run by it, the correct expression is only eight words: model decision-making, running by it. Don't say "I've got a deal to call."
The depth of questioning is one order of magnitude different:
You say which floor the boundary is, you have to get ready for that level of inquiry. To say that an agreement has been reached by itself would be to invite the other party to examine the details of the agreement and ask the normative level to collapse immediately.
The most expensive interview was not less advanced, but more advanced but unchallenged. A rhetoric that cannot be sustained is much worse than a truth.
The same test of judgment can be applied to all expressions: the phrase goes out, the other side asks three levels, can you catch it? If you can't, you can't.
VI. Three more hard wounds at the curriculum vitae level
The first is that both projects have written "to date". The interviewer will count your parallels and your length of service, both of which are not valid in logic today, and will be tantamount to inviting him to doubt the truth. The change is to say which is the main line, which is the parallel sideline, and each has a month in the time zone. The gap can be explained, and the logical contradiction cannot be explained.
The second is the order of items. The first screen determines what he asks first, given that the interviewer ' s attention is limited. This is my own judgment and is not in this wrap-up.
The third is project trade-offs. Four items should be deleted, and the judgement should be that the focus should be expanded to the core; indeed, the most relevant one should be deleted. It takes two conditions to determine which deletion is necessary: the least relevant to the target job, and you cannot say three details. The retention of a non-movable back-end item would be more damaging than the deletion of it, since the non-movable point was the point of reduction.
AI Collaborative development: division of labour and verification
It's not about interviewing skills, but it's about deciding if you have a real project.
Position: When using AI, put AI as employee, you're the boss.
Do not let a model do everything by its capacity:
The last line is worth pursuing. Using a model from the same manufacturer, both sides lose sight of the same type of error and the test becomes self-identification. The value of the cross-producer choice is not greater than that of the wrong model.
Three document principles: to bind the output of AI first to a technical document, rather than to allow it to write a code first; to enter the repository with the document and the code together, and to throw the document either after or after writing; and to test the driver, to allow AI to generate examples of testing before writing.
Duplicate actions are Skilled, such as automatically generating submission information, online problem queuing, code searching. Skill will not be called correctly by three things: the trigger keyword of the engagement scenario, the execution of the model, and allowing the model itself to review the validity of this tool call after the end of the mission.
There are three other things that are known: AI, long-run missions stuck or timeout, actively interrupting progress, filling in information, etc.; context, which is actively compressed, summarizes the historical conversation into a document and reads back in the new window; multi-window division, with the architect having a window, developing several windows in parallel, reviewing a window in code, and breaking it down according to the need for vertical decoupling.
Concluding remarks
Back to that mapping relationship at the beginning. The problem distribution of interviewers is equal to the weighting of the curriculum vitae project, which is not a bastion but a corollary of information asymmetries.
So the move was not to add a line to the resume, but to extend the project to a three-round chase: the first asked you how to do it, the second asked why, and the third asked questions.
It's gonna hold. It's in the right direction. It's gonna hold.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.