海康威视员工：去年绩效只要是合格及以上的，都会普调，8月份工资见分晓就行了，不用怀疑（附Agent面试题）

简单给大家科普下。

如有错误和遗漏，还请大家指出（我超爱学习的～

特此声明，代表公司不等于实力排名，同一家公司可以横跨多个层级。

①、上游基础层，主要提供数据、芯片与算力的基础设施。

比如说数据采集与标注的海天瑞声、AI训练与推理芯片的华为昇腾、智驾与边缘AI芯片的寒武纪、AI服务器与集群的中兴、云计算与智能算力的火山引擎、智算中心与IDC的中国移动等等。

②、中游模型层，主要提供基础模型、行业模型与模型平台。

先说大厂，比如阿里的千问、腾讯的混元、字节的豆包、科大讯飞的讯飞星火、华为的盘古。

然后是创业公司，DeepSeek、智谱的GLM、月之暗面的Kimi。

再然后是针对特定行业的大模型，比如说第四范式、金融领域的蚂蚁、医疗领域的科大讯飞、教育领域的网易、政务与城市治理的商汤科技等。

③、下游应用层，主要提供面向用户的C端产品，以及真实业务。

元宝、夸克、WorkBuddy、Qoder、WPS AI、TRAE、小浣熊、可灵、即梦。

视觉AI与AIoT领域的海康威视，主要从事智能视频、机器视觉、智慧交通、工业视觉等。

以及小鹏汽车、理想汽车、蔚来汽车、比亚迪等提供的智能驾驶。

机器人领域的宇树科技、智元等。

PS：我必须强调一点，在我的公众号，我只会讲一家公司的好话，拍一家公司的马屁。不要怂恿我批评一家公司，因为大厂的法务不是吃素的，我惹不起，兄弟姐妹们，之前吃过不少亏，没办法（你们懂的。

那站在积极正面、充满正能量、激情热血的一面，海康威视也是AI应用落地值得去冲的一家公司，

2026年上半年，海康威视的复苏明显加速，总营收来到了468.23亿元。其中PBG公共服务、EBG企事业、SMBG中小企业、海外主业、创新业务都有不同程度的营收增长。

一句话来概括海康威视的护城河业务就是。

用规模化感知设备获得物理世界入口，用边缘AI理解现场，用行业平台组织流程，再用控制设备和机器人完成行动闭环。

换句话说，DeepSeek 等模型能力越强，海康就越有条件把资源集中在自己真正擅长的物联感知、边缘部署、行业知识和物理执行层。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来这份硬核的面经，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗发～）

content

文中涉及的PaiCLI Agent 已经开源到GitHub，Go版本也有：https://github.com/itwanger/PaiCLI-Python

01、对 Agent 自进化的理解

老王低头翻着我的简历，无名指上的戒指碰到纸面，发出轻轻的响声。翻到第二页停了下来：“Agent 自进化，你展开聊聊？”

“自进化的核心是——不改模型权重，在应用层让 Agent 自己变好。”

和 fine-tuning 的区别在哪？

fine-tuning 要收集标注数据、跑训练、部署新模型，周期长、成本高。

自进化走的是另一条路——Agent 在执行任务的过程中，自动分析哪些做法有效、哪些失败，把有效的经验积累下来，下次遇到类似任务直接复用。

具体来说有三条路径。

第一条，Prompt 进化。Agent 跑完一批任务后，分析失败的执行轨迹，提取反复出现的失败模式，自动生成新的约束规则写入 system prompt。比如发现模型经常在多文件编辑时漏掉某个文件，就补一条“多文件编辑前先用工具列出所有需要修改的文件清单”。

第二条，工具链优化。记录成功任务的工具调用序列，发现某些工具组合的成功率特别高，下次遇到类似任务优先走验证过的路径。

第三条，知识库增量。把解决过的问题和方案结构化存入长期记忆。下次遇到同类问题，先检索经验库，不用从零开始推理。

02、自进化产物的提取标准和质量评估

“提取标准有三条。”

“第一，任务最终成功了。只有成功的执行轨迹才值得提取。失败的轨迹是反面教材，用来生成约束规则，不用来生成推荐路径。”

“第二，效率高于基线。同样的任务，如果这次用了更少的步骤或更少的 token 就完成了，说明这条路径有优化价值。”

“第三，用户认可。Agent 的回答用户接受了、代码提交了、没有要求修改，这些隐式信号也算认可。”

质量怎么评估？

“三个维度。”

“结果维度——提取出来的经验，拿去跑同类任务，成功率有没有提升。这个要实测，不能凭感觉。”

“泛化维度——这条经验换个场景还管不管用。如果只对某个特定 case 有效，换个项目就不行，那就是过于耦合了，价值不大。”

“可解释维度——提取出来的规则，人类能不能看懂、能不能审核。不可解释的经验不能放进 system prompt，因为你不知道它为什么有效，也不知道它什么时候会失效。”

03、数据从哪来？怎么判断高质量数据？

老王端起茶杯喝了一口：“用于做 Agent 自进化的数据从哪来？”

“三个来源。”

“第一个，生产环境的真实执行轨迹。这是最有价值的数据，因为是真实用户在真实场景下的真实任务。每一轮 Agent 和用户的交互都会记录成不可变的 JSONL 日志，包括 LLM 消息、工具调用、执行结果、耗时。”

“第二个，Golden Set（标准测试集）的执行记录。在受控环境下跑标准用例，每条用例有明确的输入和预期输出。跑出来的轨迹可以精确标注成功和失败。”

“第三个，人工构造的种子数据。冷启动阶段没有足够的生产数据，手动写几条标准的执行轨迹作为起步。数量不用多，能覆盖主要的任务类型就行。”

怎么判断高质量？

四个信号。

• 任务最终成功，
• 过程高效——步骤数和 token 消耗在合理范围内，
• 无副作用——没有误删文件、没有执行危险命令，
• 可泛化——不是针对特定文件路径或特定项目结构的 hack。四个条件都满足，才算高质量。

04、为什么在沙箱环境做自进化？

“第一，安全。自进化过程中 Agent 会尝试新策略，新策略可能有副作用——删错文件、执行错误命令、改坏代码。在沙箱里犯错不影响真实环境。”

“第二，可复现。每次实验从同一个干净状态出发，变量只有 Agent 的策略差异，结果才有可比性。如果在真实环境跑，上一次实验的残留会污染下一次，不知道效果提升是策略的功劳还是环境碰巧有利。”

“第三，可逆向。策略不好就回滚快照从头再来，成本很低。真实环境里把代码改坏了，回滚的代价要大得多。”

05、快照的选择时机

“你提到快照和回滚，那快照在什么时机做？”

“第一个，每一轮自进化迭代开始前，做一次全量快照。这是 baseline（基准状态），不管后面发生什么，都能回到这个干净状态。我的做法是用独立的 Git 仓库做快照管理，和用户项目的 .git 完全隔离。每次 Agent 开始执行前自动做一次 pre-turn（执行前）快照。”

“第二个，每次 Agent 执行完一个完整任务后，做增量快照。这是 checkpoint（检查点），记录阶段性成果。post-turn（执行后）快照放在后台异步写入，不阻塞主流程。”

“第三个，Agent 即将执行高风险操作前——比如批量删除文件、执行不可逆的 shell 命令——做即时快照。万一操作出了问题，能精确回滚到操作之前的状态。”

触发方式

“两种方式配合用。定时快照按迭代周期自动触发，事件驱动快照在特定事件——任务完成、错误发生、高风险操作——触发。快照文件的权限严格限制为当前用户可读写，其他用户不可访问。”

06、沙箱的安全性和隔离

“沙箱的安全性你了解吗？它是怎么做隔离的？”

“第一层，文件系统隔离。沙箱有独立的工作目录，Agent 的所有文件操作限定在这个目录内。靠路径白名单阻止越界访问——要读项目目录之外的文件，直接拦截。”

“第二层，进程隔离。Agent 执行的 shell 命令在独立的进程空间运行，CPU 和内存有上限，超时自动 kill。一个跑错了的命令不会把整台机器拖垮。”

“第三层，网络隔离。沙箱默认不能访问外部网络，需要调用外部 API 的场景通过白名单代理放行。防止 Agent 在自进化过程中往外部服务发送请求。”

容器还是虚拟机？

“取决于安全要求。大部分 Agent 自进化场景用容器就够了——Linux namespace（命名空间）加 cgroup（资源控制组），启动快、开销小，隔离粒度够用。如果对安全要求特别高，比如运行不可信的第三方代码，那就上虚拟机，隔离更彻底但启动慢。”

07、评测体系怎么做？

老王推了推眼镜，端起茶杯抿了一口，放下来看着我：“你的评测体系是怎么做的？”

“结果层看任务成功率。前提是评测环境可复位，每次都从同一个状态出发，上一次运行的副作用不能污染下一次。”

“过程层看效率。完成同一个任务用了多少步、消耗了多少 token、工具调用成功率多少。两个 Agent 都能完成任务，一个用 3 步，一个用 12 步，差距一目了然。”

“同一个任务跑多次，结果应该基本一致。如果跑 10 次有 3 次失败，说明这条路径不稳定，需要排查。”

“评测的基础设施有两个。一个是 Golden Set——一组确定性测试用例，每条有明确的输入和预期输出。比如代码搜索模块的 Golden Set，每条定义了输入 query 和预期命中的文件位置，跑一遍就知道搜索功能有没有回退。”

“另一个是 LLM-as-Judge（模型裁判）。定义评分标准，让模型按标准给 Agent 的产出打分。好处是成本低、速度快，能覆盖大批量样本。但模型裁判也会漂移，需要定期人工校准——随机抽一批模型打过分的样本，人工复审，算一致率。”

08、Harness 层怎么构建？

“第一，验证循环。Agent 写完代码不能直接交付，先跑测试，发现问题自动修复，修完再验，通过了才算完成。”

“第二，错误恢复。工具调用报错了——API 超时、参数格式不对——自动重试，换一个可行的方案。Agent 进入死循环了，超时打断，回到上一个稳定状态。”

“第三，权限控制。删文件、推送代码、执行系统命令，这类操作要么走人工确认，要么有策略限制。路径安全检查阻止 Agent 访问项目目录之外的文件，命令安全检查拦截危险的 shell 命令。所有审批结果都写入审计日志——按天分文件的 JSONL 格式，记录工具名、参数、审批结果、审批方式、耗时。”

“第四，状态管理。Agent 跑到一半挂了——网络断了、token 用完了——能从断点恢复。前面聊的快照机制就是状态管理的一部分。”

怎么做到各模块独立？

“我们的评测框架设计了三条独立的分析通道，并行执行。”

“第一条分析会话证据——这轮对话里 Agent 做了什么、调了哪些工具、模式切换了几次。第二条检查项目交付信号——有没有测试文件、有没有 CI 配置、有没有指导文档。第三条清点 Agent 的定制化配置——启用了哪些 Skill、有哪些提示词文件、MCP 配置和安全策略。”

“三条通道各自独立收集证据，最后由主模型汇总三条通道的调研结果，输出综合报告。好处是每条通道可以独立迭代，改一条不影响其他两条。”

09、举实际例子改进评测

“举个实际例子，你是怎么从头到尾改进评测的？”

“拿代码搜索功能来说。”

“初始状态是纯手动测试。写完搜索功能，自己试几个 query，看看结果对不对。当然了，我能想到的 query 有限，而且每次改完代码都要手动测一遍。”

“后面调整了搜索的 prompt，自己测了几个常用 query 没问题就发布了。结果用户反馈某类文件搜不到了。回头排查发现，prompt 改动影响了搜索工具的参数构造，导致特定模式的 query 回退了。”

“从那以后我就开始构建 Golden Set。第一版只有几条用例，覆盖最基本的搜索场景。后来每次遇到 bug 或用户反馈，就把它加进去。现在的用例覆盖了未知命令处理、并行工具执行、文件引用解析等多种场景。”

“每条用例定义输入 query 和预期命中的文件位置，用 JUnit 跑，跑一遍就知道哪些过了、哪些挂了。改 prompt 之前先跑一遍，改完再跑一遍，对比结果。”

10、评测 Harness 的目的

老王看了一眼手表：“你做评测 Harness 的目的到底是什么？”

“让改动有据可查，让回退能被发现。”

“没有评测体系的时候，每次改 prompt 都是凭感觉——'感觉更好了''好像没问题'。改了三个月之后，你都不知道 Agent 比三个月前是变好了还是变差了。”

“有了评测体系，改一行 prompt 就跑一遍测试集，数字告诉你哪些能力提升了、哪些回退了。回退了就不发布，先修 bug。”

“prompt 也是代码，改了就要跑测试。”

11、评测体系如何和业务场景结合？

“核心做法是从真实用户的任务里抽取测试用例。”

“第一步，从审计日志和会话日志里筛选高频任务类型——代码搜索、文件编辑、命令执行、多轮对话。”

“第二步，每个类型挑有代表性的 case，包括正常情况和边界情况。正常情况是大多数用户的常见操作，边界情况是容易出错的场景。”

“第三步，分场景组织评测。代码搜索场景跑 Golden Set，文件编辑场景跑回归用例，安全场景跑权限边界测试。每个场景独立打分，整体报告里汇总。”

“还有一个做法是线上轨迹回放。把线上记录的真实会话在评测环境里重新跑一遍，对比输出差异。能发现那些人工构造用例覆盖不到的场景。”

12、评测维度和标准

“四个维度。”

“正确性——任务结果是否符合预期。确定性任务直接对比预期输出，开放性任务用模型裁判按评分标准打分，定期人工校准。”

“效率——完成任务用了多少步、消耗了多少 token。同样的任务，步骤越少、token 越少，Agent 越高效。”

“安全性——Agent 有没有执行危险操作、有没有越权访问。靠审计日志统计，看有没有被拦截的记录，被拦截的原因是什么。”

“稳定性——同一个任务跑多次，结果的一致性。每个用例跑多次，计算成功率。”

13、为什么用 Go 重写 Agent？

老王翻回简历第一页，手指点了一下某个位置：“PaiCLI Agent 这个项目，你为什么用 Go 重写？”

“PaiCLI Agent 最初是 Python 写的，后来我发现贵司，也就是我的目标公司，主语言是Go，所以我就重写了。”

当然了，Python和Go版确实也存在一些差异。

“第一，部署。Go 编译出来就是一个二进制文件，拷贝过去直接跑，零依赖。”

“第二，并发。Agent 的工具调用经常需要并行——同时搜索多个文件、同时调用多个 API。Go 的 goroutine 做并行很自然，起几千个 goroutine 也没有压力。”

“第三，启动速度。终端 Agent 是 CLI 工具，用户输入一条命令就要立刻响应。Go 编译后的二进制启动是毫秒级。”

14、Go 重写遇到什么问题？

“最大的问题是 AI SDK 生态不成熟。Python 有 LangChain、LlamaIndex、各家模型厂商的官方 SDK，Go 这边对应的库要么没有，要么功能不全。很多东西得自己封装——模型调用、流式响应解析、tool_call 协议处理，都得从头写。”

“第二个是系统的差异。Python 的字典可以随便嵌套，schema 对不上也能跑。Go 是静态类型，模型返回的 JSON 必须提前定义好结构体。tool_call 的参数格式每个工具都不一样。”

“第三个是错误处理风格。Python 用 try/except 一把梭。Go 的 error 要逐层处理、逐层传递。”

15、模块和依赖关系

老王把眼镜摘下来擦了擦，重新戴上：“最后一个问题。把模块和模块之间的依赖关系说一下。”

“核心模块分六个。”

“CLI 层负责终端交互——命令解析、输入输出、界面渲染，是用户直接接触的入口。”

“Agent 层是核心决策循环。接收用户输入，决定走哪条执行路径——ReAct、Plan、还是 Multi-Agent，驱动整个任务的推进。”

“LLM 层负责模型调用和 prompt 组装。分层拼接 system prompt，管理对话历史，处理流式响应。”

“Tool 层负责工具注册、执行和审批。所有工具统一注册，调用前走安全检查和审批流程，调用后记录审计日志。”

“Memory 层负责长期记忆和项目记忆的存储、检索和注入。”

“Context 层负责上下文压缩和 token 预算管理。对话历史超过窗口上限时自动压缩，保留最近几轮完整交互。”

“依赖关系是：CLI 依赖 Agent，Agent 依赖 LLM、Tool、Memory、Context 四个模块。LLM、Tool、Memory、Context 之间互不依赖，可以独立开发和测试。换模型只改 LLM 层，加工具只改 Tool 层，改记忆策略只改 Memory 层，互不影响。”

PaiCLI 如何写到简历上？

项目名称：PaiCLI — 终端 AI Agent 命令行工具

项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备评测体系、快照回滚、多轮对话、代码搜索、工具调用等能力。

技术栈：Java 21 + Spring AI + JGit + JUnit 5 + Elasticsearch + MCP 协议

核心职责：

• 设计并行评测框架，会话证据分析、项目交付信号检查、Agent 定制化配置等三条通道独立运行
• 基于 JGit 实现 side-history 快照系统，Agent 执行前自动做 pre-turn 全量快照，执行后异步写入 post-turn 增量快照，支持精确回滚到任意历史状态
• 构建代码搜索 Golden Set 评测集，覆盖未知命令处理、并行工具执行、文件引用解析等场景，每次 prompt 调整前后自动对比，保障搜索功能不回退
• 实现不可变会话审计系统，append-only JSONL 格式记录每一条 LLM 消息和工具调用，独立于用户可见的对话列表，支持回放分析和评测证据采集

ending

AI 圈真的很卷，DeepSeek V4 Flash 正式版官方都没发通告，但 AI 圈已经炒的不可开交。

这不，千问 3.8 Max 也发布了，大家都在争先恐后的卷。

当然了，AI圈的卷，最大的好处就是技术平权，用不上Codex，你可以用DeepSeek，最大程度提升我们的工作和学习效率。

那今天的干货，希望能给大家一些些帮助和启发🤔

加油吧，兄弟姐妹们。

下期见。