字节 Agent 开发一面：上下文工程、协作与编程基础（2026 年 8 月）
面经与参考答法
字节 Agent 开发一面：上下文工程、协作与编程基础（2026 年 8 月）
公司：字节跳动；岗位：Agent 开发；招聘场景：日常实习；轮次：一面。帖子发表于 2026 年 8 月，原文未给具体面试日。
背景、经历及提问范围来自候选人自述，未独立证实。原题按可见记录归纳；各题下的答题思路为教学整理，不代表作者实际作答或企业标准答案。
（1）怎样介绍一个 Agent 项目的功能、外部服务和核心实现？
先用一个真实任务串起入口、目标、模型、工具、状态和验收结果，再说明外部依赖的权限、失败语义和数据边界。核心实现应挑一个最影响成功率的决策，例如上下文选择、工具结果验证或长任务恢复，依次讲约束、方案取舍、实现和指标。
Prompt 应视作有版本、有测试样本的程序配置，而非神秘配方。说明它如何约束输出格式、何时调用工具、缺少证据时怎样停止，并用固定任务集和失败样本验证改动。
（2）会话和上下文怎样管理？Token 预算为什么不能只按字符数估算？
会话状态应分离保存：当前目标、计划、已验证事实、工具证据和近期对话进入短期上下文；跨任务仍有价值的偏好或经验进入长期记忆，并保留来源、权限、时间和置信度。每轮按任务相关性、可信度和 token 预算组装上下文，而不是把全部历史拼接进去。
Token 由模型使用的 tokenizer 切分，中文、代码、标点和不同模型的切分差异很大，字符数只能粗略预估。预算还要给系统指令、工具调用、模型输出和重试留空间；接近窗口时应优先删除可重新获取的冗余内容，而不是挤掉约束和关键证据。
延伸阅读：上下文工程、Token 与上下文窗口。
（3）上下文如何压缩，怎样确认压缩真的完成且没有丢掉关键事实？
压缩前先把必须保留的信息结构化，例如目标、约束、已完成步骤、未决问题、文件或工具证据及下一步。摘要任务应有明确 Schema、长度上限和禁止臆测的规则；原始记录外置保存，摘要只作为后续推理的工作视图。
不能只相信模型回复“压缩完成”。对机器可检查字段做 Schema 校验，对关键事实保留可追溯引用；在代表性任务集上比较压缩前后的任务成功率、事实恢复率和 token 成本。若验证不通过，回退到原始上下文或更细粒度分段摘要。
延伸阅读：上下文压缩、摘要与裁剪。
（4）Skill 怎样管理和按需加载？
把 Skill 当作版本化的任务能力包：包含适用条件、操作步骤、可用工具、输入输出约束和验收方式。注册表应保存名称、描述、权限、依赖和版本；路由阶段先根据任务选择候选，再只加载最小必要说明和资源，避免无关内容挤占上下文。
加载不是授权。实际工具调用仍需服务端鉴权、参数校验、预算和审计；对 Skill 做回归评测，观察选择准确率、任务成功率、成本以及不应调用时的误用率。
延伸阅读：Agent Skill 设计。
（5）单 Agent 和多 Agent 怎样选择？
默认从单 Agent 加确定性工作流开始，它的状态、权限和调试路径最简单。只有子任务可独立并行、需要不同工具权限、上下文隔离能减少干扰，或角色间确有独立验收标准时，才拆成多个 Agent。
多 Agent 必须定义任务 ID、输入输出 Schema、状态所有者、截止时间和合并规则。它会增加通信、重复上下文和冲突成本；如果只是把同一模型串联几次，却没有可测收益，通常不值得增加编排复杂度。
（6）进程和线程有什么关系？
进程提供独立虚拟地址空间、文件句柄等资源边界；线程是进程内可被调度的执行单元，线程共享进程内存与大多数资源。共享使线程通信快捷，也要求同步来避免竞态；进程隔离更强，但创建与通信一般更重。
实际设计还要讨论任务性质：CPU 密集型任务受核心数限制，I/O 密集型任务可提高并发；无论使用线程池还是多进程，都要限制队列、传播取消与超时，并防止共享状态无序增长。
（7）从输入 URL 到页面展示有哪些关键阶段？
浏览器解析 URL，进行 DNS 查询，建立或复用安全连接，发送 HTTP 请求并处理缓存、重定向和响应。随后解析 HTML，加载 CSS、脚本和子资源，构建渲染相关结构并完成布局、绘制与合成；脚本执行、长任务和资源优先级都会影响可见时间。
排障应区分网络获取慢、服务端首字节慢和浏览器渲染慢，分别用网络瀑布图、服务 Trace 与性能面板验证。
延伸阅读：前端性能诊断。
（8）MySQL 如何去重？ROW_NUMBER() 适合什么场景？
预防重复优先靠唯一约束和幂等键；查询时可用 DISTINCT 去掉选择列完全相同的行，或用 GROUP BY 按业务键聚合。清理重复记录时，窗口函数可以按业务键分区、按时间或主键排序，再保留 ROW_NUMBER() = 1 的记录，其余作为待处理重复项。
例如 ROW_NUMBER() OVER (PARTITION BY user_id, type ORDER BY created_at DESC, id DESC) 表示给同一业务键内的记录编号。执行删除前必须先检查保留规则、并发写入和索引，最好在事务和可回滚备份下分批处理。
（9）Linux 怎样查看进程与端口？
可先用 ps 按 PID、命令和资源情况定位进程，用 ss -ltnp 查看监听 TCP 端口与关联进程；在权限允许时，lsof -i :端口号 也能定位占用者。排查连接问题还要区分监听、已建立连接、TIME_WAIT 和防火墙规则，不能看到端口号就断定服务健康。
线上操作应先确认环境和目标 PID，再采用可回滚、最小影响的动作，并记录诊断证据；不要用模糊的进程名批量终止服务。
（10）数组、链表和哈希表冲突怎样回答？
数组内存连续，随机访问和顺序扫描效率高，但中间插删往往需要移动元素；链表节点分散，已知节点位置时插删方便，但随机访问慢且指针开销和缓存未命中更多。选择取决于访问模式，不只是大 O。
哈希表把键映射到桶，冲突可用拉链法或开放寻址处理。拉链法在负载升高时链变长，开放寻址对装载因子和删除标记更敏感；两者都应扩容和重新散列以维持平均 $O(1)$ 查询。对抗性输入下还要考虑安全哈希和退化保护。
（11）怎样合并两个嵌套 JSON，同时不修改原始输入？
原帖提及的JSON示例图未取得完整题面，不能还原图中全部输入。以下合并规则是教学示例，原帖没有给出所有类型的冲突合同，面试时须先澄清；不能把它当唯一标准答案。先定义类型规则并实现纯函数：两个对象按 key 递归合并；两个数组拼接；两个数字相加；两个字符串拼接；两个布尔值取逻辑或；其余组合由右侧覆盖。递归前应识别数组和对象，避免把数组当普通对象；返回的新对象、新数组与可变值都要复制，不能复用后续会被写入的引用。
测试至少覆盖嵌套对象、仅一侧存在的 key、空数组、false、0、null、类型不一致和输入对象不变。复杂度与两份输入中被访问节点数成正比，过深数据还应防止递归栈溢出。
延伸阅读：递归、分治与搜索。
教学补充：用一个任务复习与迁移
以会话需要保留“只读租户 A”约束为例：运行时从授权会话绑定 A，压缩前把只读要求及证据引用放入独立状态，摘要只生成工作视图；子任务收到结构化合同后再查询。若摘要流畅却漏掉 A 或只读条件，字段和权限校验应阻止执行，而不是让子 Agent 猜。
口述要点：上下文是工作视图，租户、权限与关键事实独立保存并在执行时验证；摘要遗漏就回源或阻断。数据结构和SQL选择要围绕访问、排序和变更合同，不能把框架或高分当正确性证明。
下面是模拟变条件追问，不是来源面经原题：
- Skill 按需加载成功，是否自然获得写数据库权限？——说明加载是上下文选择；实际工具调用仍由运行时鉴权与预算校验。
- 两个 session 都写同一个文件，会自然隔离吗？——不会，工作目录和可变状态还要有所有者、版本与合并合同。
整理答案的核验资料
核验于 2026-10-02。LangGraph 为滚动文档；MCP使用2026-07-28规范，MySQL使用8.4。未声称执行了作者的项目或复现其面试。
- LangGraph memory：摘要与持久状态
- MySQL8.4 ROW_NUMBER
- Linux man-pages维护者：pthreads共享资源
- iproute2维护者手册：ss -l/-t/-n/-p（权限影响进程信息可见性）
- Chrome维护者：Renderer parsing/layout/paint/compositing（2018架构说明，采用阶段机制而非声称所有现行细节）