字节飞书低代码平台 后台开发一面

原题1： 工作有搭 agent，为什么不采用 workflow 或者 prompt+大模型？拆解： 这是整场面试最致命的一题。面试官不是在否定 agent，而是在考你技术选型的决策逻辑——你是否真的理解 agent / workflow / prompt 三种方案的适用边界。• Prompt+大模型：适合单轮、无外部依赖的简单任务。快，成本低，但上限也低• Workflow：适合多步骤但路径确定的流程，可以并行调用不同服务，可控性强• Agent：适合路径不确定、需要自主规划和工具调用的复杂任务，灵活但稳定性差面试官追问「觉得没有必要用 agent，让我说 agent 具体做了什么」——说明你的 agent 场景没能说服他。核心问题是：你无法清晰说出 agent 在这个场景下的不可替代性。如果 workflow 也能做，那你为什么要上 agent？答题框架： ①先承认「这个场景确实可以考虑更轻的方案」②然后说明为什么在这个场景选了 agent（比如说，用户的输入不可预测、需要动态选择工具链）③最后给出 agent 带来了什么 tradeoff（灵活性 vs 稳定性）───原题2： agent 使用弊端拆解： 这题考的是对技术的批判性认知。很多候选人用 agent 只会说好处，说不出弊端=你不懂。agent 的弊端至少四点：1. 稳定性差——自主决策意味着结果不可控，同样的输入可能产生不同输出2. 调试困难——不像 workflow 可以逐节点排查，agent 的黑箱决策链路很难定位问题3. 成本高——多次 LLM 调用+工具调用，token 消耗远高于单次 prompt4. 循环风险——ReAct 模式下可能陷入无限重试关键： 能说出弊端并给出 mitigation 方案才是高分答案。比如「为了解决稳定性问题，我们加了最大步数限制 + 关键节点人工审核 + fallback 到规则兜底」。───原题3： 用过飞书多维表格吗？用过哪些模块的功能？拆解： 不是闲聊。飞书AI产品岗必考题。考的是你对飞书生态的理解深度——多维也表格是飞书 AI 的核心载体之一（数据存储+工作流引擎）。说不出具体模块=没用过=对产品理解停留在表面。建议：投飞书 AI 岗之前，至少把多维表格的公式、自动化、仪表盘、AI 字段这几个核心能力吃透。通过cli发现的不错面经，如有侵权请联系删帖。

核心定义ReAct 是能让大模型“边思考、边行动”的推理框架，让 LLM 像人类一样通过多轮交互解决复杂问题Thought-Action-Observation 运转逻辑ReAct 循环中有三大要点：Thought：模型分析当前的局面，大任务拆解成子任务，决定当前最需要做什么Action：根据前面的思考结果，生成具体的操作指令Observation：接收真实环境对操作的反馈结果这就有了一个闭环：想清楚再做，做完看反馈，基于新反馈接着想ReAct + Function calling 怎么运转？在 ReAct 需要与外部系统结合时，免不了调用工具，执行链路如下：评估与决策：模型接收用户请求，判断...

“你平时使用AI编程吗？”，“一般用在什么地方？解决了什么问题？”，“用的比较多的AI编程工具是什么？用的什么模型？”当面试官问这些问题时，他到底想听到什么？他不是真的对你用的哪个模型感兴趣。我认为，他想考察的，是这三点：你的效率和学习能力： 面试官想知道，你是不是一个活在2026年的开发者。AI工具已经是这个时代的效率杠杆，能极大地提升开发效率。如果你对它完全不了解、不使用，那在他们看来，你的学习能力和对新工具的拥抱程度，可能要打个问号。你对AI工具的理解深度： 他更想听的，不是你如何用AI写了个for循环，而是你如何看待AI生成的代码。你会直接复制粘贴吗？还是会去审查、重构、测试它？这能看出你对代码质量和工程严谨性的理解。你是在使用工具，还是在被工具使用？你的对自己的定位： 这个问题，其实是在变相地问：“你的核心价值，是AI可以轻易取代的吗？” 如果你说AI主要帮你写业务逻辑 ，那你等于告诉面试官，你的核心工作正在被自动化。

什么是 Multi-Agent ？就是一个由多个分工明确的 AI 角色编排而成的协作团队。每一个 Agent 各司其职，通过互相交流协作来实现复杂任务相比单 Agent 的优点降维解耦：单 Agent 在处理庞杂任务时，容易因为上下文过长而丢失焦点或产生幻觉。多智能体让每个 Agent 只专注特定领域，挂载专属的系统指令和工具，降低模型的认知负载交叉验证：Agent 之间能互相审查与辩论。比如“开发 Agent”写完逻辑，“测试 Agent”立刻跑测试用例挑错，这就是为什么一般流程后会加一个 correct_node非必要不升级一定要多 Agent 吗？一个需求，能用函数解决就优先函数，函数解...