宇宙厂员工：三年了，今年晋升+涨薪，火山方舟侧业绩不错，但新老板只打了m，同时帮我争取到了涨薪，这是正常的还是我想太多（附Agent面试题）

刷到一位老哥的帖子，说自己入职三年，今年顺利晋升加涨薪，业绩也挺不错，但绩效只给打了 M，同时又帮他争取到了涨薪，心里犯嘀咕，不知道这是正常操作还是自己想太多。

说实话，三年时间能把晋升和涨薪同时拿到手，节奏已经相当稳了。

在大厂的考核体系里，刚晋升完的同学，职级上了一个台阶，对应的期望标准也会跟着提高；再加上新老板刚接手团队，手里的绩效高分名额往往要统筹平衡。老板在打 M 的同时专门去争取了涨薪预算，说明他认可你的实际产出。

火山方舟是主推的大模型服务与企业级 Agent 平台。背靠豆包大模型家族，火山方舟今年承接了大量高并发的企业级智能体项目，从多业务流程路由、复杂状态图编排，到跨请求长周期任务的断点恢复与状态存储，工程挑战还是非常多的。

我也整理了一下火山引擎覆盖到的 AI Agent，供大家参考一下。

1、扣子和 ArkClaw，争夺员工日常工作的入口。

2、TRAE，包括 IDE、插件、CLI 和 TraeWork。IDE 中的 SOLO 模式可以将复杂任务交给 Agent 规划和执行；CLI 面向编写代码、测试、Git 操作等任务；TraeWork 则向办公协作延伸。

3、iDA，覆盖数据资产查找、数据查询、Excel/CSV 处理、指标异动归因、研究和专业内容交付，并通过技能中心沉淀可复用能力。

4、Kickart 和剧创 Agent，Kickart 面向电商和营销团队，剧创 Agent 面向短剧团队，围绕剧本、角色、场景、分镜视频、素材资产和多人协作展开。

5、火山方舟承担模型服务，并向上延伸到托管 Agent；豆包、Seedream、Seedance 等模型提供推理、图像和视频能力。

6、还有 AgentKit、方舟 Managed Agents、HiAgent 等。

接下来，继续啃硬菜，每天都学一点，每天都要进步一点。

content

01、Agent项目，不同类别对应不同流程，如何保证路由准确性？如何保证处理流程按预期逻辑执行？

“为了兼顾路由准确率和响应速度，我们在入口设计了由浅入深的分级路由机制，先经过确定性指令检查，再做高置信度关键词匹配，最后才由轻量模型做结构化分类。”

“请求进来后，路由器先检查用户输入里有没有显式的模式指令，比如指定进入 plan 模式或 Team 模式，有的话直接按确定性规则分发。

没有显式指令时，路由器会查询当前会话是否已经绑定了特定的业务 Agent 或执行模式。如果当前会话正处于多轮任务中途，且新输入的意图仍然在当前 Agent 的处理范围内，系统就维持原有绑定，防止多轮对话里用户简短追问一句‘那异常情况呢’就被切换到别的流程。

只有当新请求超出了当前绑定的业务范围，或者属于全新会话时，才通过关键词匹配计算置信度，高置信度直接命中返回。

对于表达含糊、关键词置信度低于阈值的长尾请求，系统再调用轻量模型做兜底分类。分类提示词里会传入各个业务流程的职责边界与正反例，强制要求模型输出包含意图类别、置信度分数和简短理由的 JSON 结构；一旦模型返回的置信度依然偏低或标记为未知，系统会直接走默认的通用流程或反问用户澄清诉求。”

路由到对应流程后，如何保证处理流程按预期逻辑执行？

“我们的做法是把流程控制权收回给确定性的 Java 代码。”

“在每个流程启动时，提示词组装器只加载对应模式的指令集，并通过渐进式加载的 Skill 机制提供标准操作。

到了工具调用阶段，Java 代码会在执行前用 JSON Schema 严格校验工具入参，缺字段或类型不符直接报错，同时根据用户本轮的原始输入生成网址与工具授权边界，防止外部网页诱导模型越权调用。

当模型返回多个工具调用时，调度器把连续的只读工具归并到线程池并发执行，一旦遇到写文件、执行终端命令或调用外部 MCP 接口等操作，必须等只读批次全部结束后再按顺序逐个串行。”

02、你们的graph具体指什么？是专门有人来画这个图吗，怎么实现的？

“PaiAgent 里，Graph 指的是管理多节点状态流转与条件分支的状态图（StateGraph）。图里的每个节点代表一个功能执行器，比如大模型推理节点、RAG 知识库检索节点、条件分支节点或者外部工具节点，节点之间通过普通有向边或条件边连接，整张图共享一份全局工作流状态。

而在 PaiCLI 的规划模式与多角色团队模式里，Graph 指的是针对当前复杂需求，在运行时动态拆解出来的子任务依赖图。图里的每个节点是一个待完成的子任务（如读取文件、修改代码、运行命令、结果验证），有向边代表子任务之间的先后依赖与数据传递关系。”

是专门有人来画这个图吗，底层是怎么实现的？

“固定业务流程由研发或运营在可视化画布上拖拽生成，而开放式的复杂编程任务完全不需要人工画图，由大模型在运行时实时生成。”

“PaiAgent 的前端基于 React Flow 画布组件，用户把大模型、知识库检索、条件判断等节点拖到画布上连好线，保存时会序列化成一份标准的 JSON 配置，里面包含节点列表（记录节点 ID、类型、提示词模板和参数）与边列表（记录起点 ID、终点 ID 以及分支句柄）。

后端拿到这份 JSON 配置后，提供两套执行方式。如果流程不需要 ReAct，默认经过自研的 DAG 解析器，用哈希表构建前驱依赖表、后继邻接表和入度表，先把所有入度为零的起始节点放进队列，再通过 Kahn 算法执行拓扑排序；每执行完一个节点就将后继节点入度减一，入度归零即入队，若最终排序出的节点数少于总节点数，直接抛出异常。

如果流程包含审核打回这类循环回路或复杂状态路由，系统就会切换到基于 LangGraph4j 的状态图执行器。图构建器遍历 JSON 里的节点，将每个业务执行器适配成 LangGraph4j 的异步节点动作，节点执行前从全局状态字典里提取上游输出作为当前输入，执行完成后把结果和耗时写回全局状态并推送 SSE；针对条件判断节点，执行器算完表达式后会在输出里写入选中的分支标识，图构建器据此绑定条件路由边，最后编译成可执行的状态图驱动整个流程。”

03、Agent跨请求长流程、状态流转、撤销相关，底层整体架构设计是什么，采用什么设计思路？

“处理跨请求的长周期流程、状态流转与中途撤销，我们的整体架构设计思路是把计算与状态彻底解耦，做成无状态的执行器配合外置的只追加事件日志（Append-only Log）与多级检查点快照（Checkpoint）。

之所以采用这种思路，是因为 Agent 的长任务随时可能因为等待人工审批（HITL）、等待外部异步回调、客户端网络断开或者服务进程重启而中断，如果把执行状态绑在单次 HTTP 请求线程或进程局部变量里，一旦断连整个长流程就作废了。”

“在跨请求任务架构上，我们在服务层暴露了基于会话线程的 HTTP 接口与持久化的后台任务队列。客户端发起任务请求时，服务端先在数据库里创建线程记录，并把任务以待执行状态写入持久化任务表，立即向客户端返回线程 ID，客户端随后通过带游标序号的 SSE 流式接口订阅进度事件，断线重连时只要传上一次收到的事件序号就能无缝连接。

后台工作线程池轮询任务表时，在本地事务里通过带状态条件的更新语句（将指定 ID 且状态仍为待执行的记录更新为运行中）做原子抢占，抢占成功才启动 Agent 执行；如果服务进程意外重启，任务管理器在初始化阶段会自动扫描所有运行中的记录，将其统一标记为进程中断失败，避免僵尸任务滞留。

在会话上下文的跨请求流转上，Agent 每次产生新的 user 消息、assistant 消息和 tool 结果，都会以 JSONL 格式顺序追加到本地的会话日志文件。由于上下文压缩、清理旧工具结果或者回滚操作会原地修改内存里的消息列表，单靠从头累加原始消息无法还原压缩后的上下文，所以每当内存消息列表发生改写，Agent 都会立刻往日志末尾追加一条视图检查点事件，把改写后的完整消息视图存下来；跨请求恢复会话时，系统只需倒序找到最后一条视图检查点，再往后重放增量消息，就能还原中断前的推理现场。”

涉及文件修改或外部副作用时，撤销机制是怎么设计的？

“如果任务还在运行中途用户就按下了取消键，直接杀线程会导致内存消息列表里留下一条带有工具调用请求、却没有对应工具结果的半截 assistant 消息，下一轮发请求时大模型接口会直接报协议格式错误。

为了让运行中的取消变成有序撤退，我们设计了跨线程传递的取消令牌，并在每轮循环开始前、大模型响应返回后（追加 assistant 消息之前）、以及每个工具执行前设置了三道取消检查点。一旦在工具执行阶段收到取消信号，执行器会先强制终止正在运行的子进程树，再为这批工具调用里每一个未完成的调用编号自动合成一条‘用户取消了此次工具调用’的失败结果追加进历史，同时跳过本轮的长期记忆自动提取，保证随时停下来上下文协议都是合法的。

如果一轮对话已经执行完，用户发现 Agent 把好几个源码文件改坏了想要撤销，我们就通过 JGit 实现的外部独立版本库来做文件级回滚。系统在用户主目录的快照文件夹下，按项目路径的 SHA-256 哈希值初始化一个独立的 Git 版本库（只存放版本对象库，将用户项目根目录设为工作树，完全不触碰项目本身的 Git 目录和提交历史）。

每轮对话开始前，快照服务同步执行一次提交，排除构建产物和依赖目录，打上轮次前快照；本轮结束后再由单线程异步打上轮次后快照。当用户触发回滚指令或模型调用回滚工具要退回前 N 轮时，快照服务会先对当前工作区打一个恢复前保护快照，让‘撤销操作本身’也能被反悔；随后读取目标轮次前快照的目录树，逐个将文件内容写回工作区，并清理掉这期间新增的已跟踪文件。”

04、Agent运行的状态数据存储在哪里？

“Agent 运行期间产生的状态数据，在读写频率、数据体积和生命周期上差异很大。全放内存会在进程重启时丢失状态，频繁将大文本同步写入 MySQL 又会拖慢 I/O。因此我们按数据的冷热程度与一致性要求，采用了四级分层存储架构。”

“高频读写的活跃上下文与运行控制状态直接存放在内存中（多实例服务端对应带过期时间的 Redis）。当前会话的消息列表是发送给大模型的唯一数据源，同一回合内深度思考模型返回的推理过程字段也挂载在内存消息对象上。为控制内存与上下文开销，多模态会话上传的截图在当轮请求发送完毕后，系统会自动剥离其 Base64 字节载荷，仅保留文本描述。

顺序追加的会话日志、安全审计与超大工具输出存储在本地文件系统的受控目录中。会话日志在创建时强制设置 POSIX 0600 权限（仅当前用户可读写），防止提示词中的敏感内容泄露；高危工具的审批与执行记录按天切分写入 JSONL 审计文件；当单次代码检索或命令执行返回结果超过 32000 字符时，完整结果会转存至工作区下的独立文本文件，内存和上下文中仅保留文件路径与首尾预览片段。

需要按条件查询、事务认领和断点恢复的结构化状态存储在 SQLite 或 MySQL 中。PaiCLI 服务端模式使用本地 SQLite 维护跨请求会话、SSE 进度事件、后台任务状态以及语法树解析出的代码向量索引。

跨会话保留的长期记忆与工作区文件快照，分别存储在并发受控的 JSON 文件与外部 JGit 版本库中。

由于多个 Agent 实例可能同时读写同一份记忆文件，写入层结合了进程内可重入锁与跨进程 NIO 文件通道锁，每次更新先加锁读取磁盘最新内容，写入同目录临时文件后再通过原子改名替换原文件，防止写入中断导致 JSON 损坏；代码修改前后的文件状态则保存在前文所述的独立 JGit 版本库中。”

05、AI Coding在你的工作当中是怎么使用的？

“日常研发中我重度使用 Claude Code、Codex 以及自研的终端 Agent 工具 PaiCLI。目前的工作方式已经从早期的代码片段补全，转变为完全交由 Agent 完成规划、编码、语法自检与单测验证的完整流程。”

“在开发具体需求前，我会先把项目的模块职责、架构约束、构建测试命令与安全红线写入项目根目录的说明文档，并将高频排查与开发规范整理为独立的 Skill 文件。会话启动时 Agent 即可自动加载项目规范与目录结构，省去在对话框中重复交代背景的成本。

处理跨模块的复杂需求时，先进入 Plan 模式。Agent 会并发调用文件匹配和代码搜索工具梳理现有调用关系，输出带依赖顺序的修改计划。我重点审查计划中的数据结构设计、接口签名与并发边界，存在偏差时当场补充约束让其修订，确认方案无误后再放行，避免模型直接改动十几个文件导致架构偏离。

进入编码阶段后，要求 Agent 在修改业务代码的同时编写覆盖边界条件的单元测试，并在自动模式下调用终端工具执行 Maven 测试。PaiCLI 迭代 23 期、积累约 8 万行代码和 1800 多个单元测试的过程中，常规功能与单测均按此流程推进；代码写入后先由静态语法诊断拦截编译错误，单测失败堆栈则直接回传给模型自主定位修复，通常两三轮迭代即可全部通过。

代码调通准备提交前，我还会触发多专家并行审查命令，启动三个不带写工具的只读审查子任务，分别从逻辑缺陷、安全围栏和并发隐患三个角度并行扫描改动集，生成带行号证据的审查报告。最后的人工 Code Review 只需集中把关核心状态机流转、锁粒度、幂等防重和权限边界等关键逻辑，确保交付质量可控。”

PaiCLI 如何写到简历上？

项目名称：PaiCLI（生产级 Java 终端 AI Agent）

项目简介：对标 Claude Code 的商业级命令行 AI 编程 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，涵盖动态任务图调度、跨请求会话与后台任务持久化、三档上下文压缩、四层安全围栏与外部独立 Git 快照回滚，累计约 8 万行代码与 1800+ 单元测试。

技术栈：Java 17 + OkHttp + Jackson + JSON Schema + JavaParser + SQLite + JGit + JLine + MCP 协议

核心职责：

• 设计 ReAct、Plan-and-Execute 与 Multi-Agent 三种执行路径及分级路由调度，结合 JSON Schema 前置参数校验、只读工具并发（上限 4 线程）与写操作串行分流，消除并发编辑同一文件引发的更新覆盖问题
• 实现基于大模型的动态任务依赖图（DAG）拆解与编排引擎，严格校验节点唯一性与依赖声明，采用三色深度优先搜索（DFS）拦截循环依赖并按拓扑排序分批并发执行，支持进度未过半时携带已完成证据自动触发失败重规划
• 构建跨请求长流程与有序取消架构，基于 SQLite 落地线程级 SSE 增量事件流与后台任务条件更新原子认领；在运行循环设置三处取消检查点，中断子进程树并自动合成取消结果以维持上下文协议合法
• 落地基于 JGit 的外部独立版本库快照回滚机制，将版本库隔离在用户主目录下，每轮执行前后自动记录轮次前与轮次后快照，回滚前先打恢复前保护快照，在不污染项目 Git 历史的前提下实现文件级秒级撤销
• 搭建四级运行时状态存储体系，由内存维护单源对话历史（自动剥离历史多模态图片 Base64 载荷），结合只追加 JSONL 会话日志与视图检查点还原压缩后上下文，超大工具输出自动卸载至本地文件，长期记忆采用进程内锁加跨进程文件锁与临时文件原子替换保障并发安全

ending

今天是在学校讲课的最后一天了。

讲到口干舌燥，甚至咳嗽起来，只能说做老师确实也不容易。

希望能帮助到一部分的同学，我就很满足了。