任何技术的发展，都有可能被滥用，AI 也不例外。
我个人是强烈反对任何形式的作弊行为，因为这破坏了公平性和诚信，也会对整个行业的发展造成负面影响。
这不，就看到有员工发贴说，他们部门对 AI 作弊零容忍，逮到直接永不录用。其实作弊很明显——眼睛往一个方向瞟、切屏幕，摄像头里看得一清二楚。
大家是如何看到 AI 作弊这件事呢？
我先贴一些我看到的声音哈。
同学A：哥们不作弊线上面试全寄了，最后上岸了一家线下面的企业。同门啥也不会，靠作弊进字节爽赚大米了（世上只有一种英雄主义，就是在认清生活真相之后依然热爱生活）
同学B：事实就是很多人靠作弊拿到了offer，你不做别人也会做，不如大家一起作弊（这个世界还是需要有一批仰望星空的人，哪怕黑夜再漫长）
同学C：不是说招会用AI的人吗？那擅长用AI作弊的人怎么不算是会用AI呢，先作弊的人享受工作（bushi）
为了应对 AI 的发展，很多互联网大厂也在积极寻求改变，比如说阿里，AI 应用研发笔试的题型是这样的，12 道单选 + 11 道多选 + 1 道 AI Coding。
选择题基本围绕 Agent 展开，如果你自己完整做过 Agent 项目，基本上都能过，重点就是 ReAct、Function Calling、联网搜索、MCP、Skills、Memory 这些。
AI Coding 基本上就是一个小任务，大概 1 个小时。这种就需要你平常多用 Codex、Claude Code 这些工具进行实打实的编码。
否则哪怕是有 AI，结果也不一定称心如意，因为真正的 AI Coding，离不开古法编程的工程思维。
毕竟 AI 最大的问题就是幻觉，哪怕是最顶级的模型也不例外。目前的技术手段还没有办法完全消除，只能尽量缓解。
所以，我觉得还是要把心思花在平常的学习和积累上，毕竟目前的 AI 还只能算是一个很牛逼的工具，真正的能力还是要靠自己。
如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来的硬核内容，希望你能认真读一读。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗发～）
content
01、简单介绍一下自己的经历，以及之前参与过的 AI Agent 相关工作？
“我做过三个 Agent 方向的项目。”
“PaiCLI 是一个终端 Agent，对标 Claude Code。支持三种执行模式：ReAct 处理日常交互，Plan-and-Execute 处理需要分步骤的复杂任务，Multi-Agent Team 让规划器、执行器、审查器三个角色协作。内置了代码搜索、文件读写、命令执行、MCP 工具调用这些能力。”
文中涉及的PaiCLI Agent 已经开源到GitHub，Go版本也有：https://github.com/itwanger/PaiCLI-Python
“派聪明是一个 RAG 知识库，基于 Elasticsearch 做混合检索——向量检索负责语义匹配，BM25 负责关键词精确匹配，两路结果加权合并。支持 PDF、Markdown 等格式的文档上传和自动分块。”
“PaiAgent 是一个可视化的 Agent 工作流编排平台，后端用 LangGraph4j 做状态图引擎，前端用 ReactFlow 做拖拽式节点编排，支持 ReAct Agent 节点、LLM 节点、检索节点等不同类型的执行单元。”
02、Coding Agent 的记忆怎么做的？
“长期记忆有两种形式。一种是事实记忆，存在本地 JSON 文件里，有项目级和全局两种作用域。每轮 LLM 调用之前，记忆检索模块根据用户当前的输入查询相关记忆条目，匹配上的才注入系统提示词。”
“另一种是项目规范，通过 PAI.md 文件注入。存的是项目级别的规范和约定。和事实记忆不同的是，PAI.md 每轮都会全量注入，不走检索，也不参与压缩。”
“短期记忆就是对话历史。”
“压缩的触发条件是当前 token 数超过上下文窗口的安全线。压缩时找到所有 user 消息的位置，保留最近 3 轮用户消息和它们对应的完整交互，包括 tool_call 和 tool_result，不会把一对工具调用拆开。历史部分用 LLM 生成摘要替换，摘要强制保留四类信息：用户的核心诉求、已完成的操作、达成的共识、还没做的事情。”
03、你们的 Agent 和 Claude Code、Codex 有什么区别？
“PaiCLI 的整体架构就是参照 Claude Code 做的，执行模式基本对齐。ReAct 循环、Plan 模式、Sub-agent 多 Agent 协作都有。”
“Codex 现在有 CLI、桌面端、Cloud 和 Web 四种形态。CLI 和桌面应用在本地执行代码，跟 Claude Code 一样；Cloud 模式是每个任务启动一个云端沙箱，代码在远端容器里跑。”
“PaiCLI 做了模型抽象层，通过工厂模式创建客户端，DeepSeek、智谱、Kimi 这些都能接，改个配置就能切换。”
04、你们怎么对 Agent 去做评测的？
“首先，评测环境必须每次从同一个初始状态出发，上一次运行产生的副作用不能影响到下一次。”
“然后看完成同一个任务用了多少步、消耗了多少 token、工具调用成功率多少。”
“同时，要注意同一个任务跑多次的结果一致性如何。10 次里 7 次成功 3 次失败，说明某个环节有问题，需要排查是提示词的问题还是模型本身的波动。”
“PaiCLI 的代码搜索模块维护了一个 Golden Set，里面是确定性测试用例——定义好输入 query 和预期命中的文件行号，跑一遍就知道搜索效果有没有回退。”
“大批量评测用 LLM-as-Judge，直接让模型打分，成本低、速度快。”
“定期还要做人工校准。随机抽一批模型裁判打过分的样本，人工复审，算两边的一致率。一致率低了，要么评分标准需要调整，要么模型裁判用的基座模型自己漂移了。”
05、云 Agent 如果容器迁移或者重启了，上下文信息怎么办？
“把所有状态外置，容器本身做成无状态的。”
“对话历史做 Redis 加数据库双写。Redis 存热数据，以及最近的对话轮次，访问快，记得设一个过期时间。MySQL 存完整历史，永久保留。容器重启后先从 Redis 恢复最近对话，Redis 丢了的就从数据库兜底。”
“任务计划一定要持久化到数据库。执行计划里每个任务都要有状态标记。重启后读取执行计划，找到最后一个'执行中'或'等待中'的任务，从那里继续。保证已完成的不会重做。”
“再加一个 checkpoint 机制。每完成一个任务做一次状态快照，把当前的对话摘要、已完成的任务列表、工作目录的文件变更清单都写到数据库。恢复时加载最近的 checkpoint，然后同步文件状态，继续执行。checkpoint 粒度按任务走，每个 task 完成后做一次，对写文件、执行系统命令这些可能产生副作用的操作，在操作前额外做一次，确保操作失败时能回滚到操作前的状态。”
06、Goal 这里怎么做任务持续推进而不行为漂移？
“用户的原始目标放在系统提示词的静态层，模型每一轮都能看到。不要放在对话历史里——因为对话历史会被压缩，目标可能被摘要稀释掉。”
“然后是结构化任务列表。用 Plan 模式把目标拆解成一个带依赖关系的任务列表，每个任务有明确的描述和状态。模型每一轮看到的信息里包含哪些任务做完了、哪些在等待、当前在做第几个。做完一个划掉一个，下一步该做什么一目了然，就像看板一样。”
“另外，系统提示词里要有明确指令——如果当前操作偏离了主线目标，停下来重新评估。配合工具调用的审批机制，写文件、执行命令这些高风险操作需要确认。”
“触发压缩时一定要保留目标。对话历史压缩的摘要模板强制保留四类信息：核心诉求、已完成操作、达成共识、待办事项。核心诉求就是用户的原始目标，不管压缩多少轮都要记得。而且目标信息要存两份，系统提示词的静态层一份，压缩摘要的核心诉求字段一份。”
07、Coding Agent 接的什么模型？
“PaiCLI 做了模型抽象层，通过工厂模式创建 LLM 客户端，目前支持 DeepSeek、智谱、阶跃星辰、Kimi 等。”
“选模型看三个指标。代码生成质量——Coding Agent 的核心动作就是写代码，这一项直接决定任务成功率。工具调用准确率——Function Calling 参数格式对不对、调用时机准不准。上下文窗口大小——窗口太小的话多文件编辑时上下文装不下，压缩频率会变高。”
“成本控制靠 Prompt Caching。静态内容（身份定义、工具描述、安全策略）固定排在 prompt 最前面，整个会话保持不变。缓存命中和没命中的价格能差数十倍。另外，复杂任务可以用大尺寸模型，简单任务用小尺寸模型，按任务难度动态切换。”
08、你认为在模型能力强的前提下，Agent 最重要的是什么？
“Harness。包括工具定义、权限控制、上下文管理、错误恢复这些。”
“Agent 的 ReAct 循环本身很简单——接收输入、调用模型、执行工具、观察结果、再调用模型。差距出在 Harness 里的工程细节里。”
“比如说工具要有白名单，路径要有访问限制。模型能力越强，没有约束时犯错造成的破坏性越大。”
“比如说工具调用失败了能自动重试，文件改坏了能回滚。PaiCLI 做了 Side-Git 快照，每次写文件前自动存一份，改坏了能一键恢复。”
“比如说上下文管理。该给模型看什么、不该看什么。一个 grep 搜索返回几百行结果，全塞给模型，中间的内容大概率会被忽略。好的 Harness 会做摘要和筛选，把关键信息放在模型注意力集中的位置。”
09、模型注意力的上下文 Lost in the Middle 你了解什么原理吗？
“把相同的相关文档分别放在长上下文的不同位置，模型的回答准确率差别很大。结果是，LLM 在处理长上下文时注意力呈 U 形分布，放在开头的文档准确率大约 75%，放在中间的降到大约 55%，差了 20 个百分点。”
“更极端的情况，给模型塞 20 篇参考文档，效果反而不如一篇都不给。噪音把有用的信息淹没了。”
“原因和 Self-Attention 的计算方式有关。每个 token 要和上下文里所有其他 token 计算注意力权重。位置编码（比如 RoPE）会根据 token 所在位置进行旋转变换，不同位置的 token 在注意力计算中的贡献不同。训练数据的分布也有影响，文档开头通常是摘要、结尾是结论，信息密度比中间部分要高，模型在训练过程中学到了对头尾位置投入更多注意力这个模式。”
“对于 Coding Agent 来说。长上下文里包含多个文件的代码，中间文件的分析结果容易被忽略。工具调用可能返回了大量搜索结果，排在中间的结果可能会被模型跳过。多轮对话中，早期的重要上下文被压到了中间位置，模型就会忘了之前做过的重要决策。”
“应对方案有三个。第一，关键信息放两端，比如说系统提示词放在上下文开头，当前任务和最近一轮交互放在结尾。第二，不要等窗口塞满了才压缩，差不多占到窗口的 80% 就触发压缩。第三，对于多文件编辑这种大任务，拆成多个 Sub-agent，每个只处理一个模块，各自拿到独立的上下文窗口，主 Agent 只接收结果摘要。”
场景题
如果希望通过 Agent 实现广告投放策略的自动优化，你会怎么设计？
“整体分三个模块。”
“数据采集模块负责从广告投放平台获取数据。字节就有巨量的引擎 API，可以定时拉取各个维度的指标，比如说展示量、点击率、转化率、单次转化成本、ROI。除了自身投放的数据，还要采集行业基准做对比参照。数据拉取回来后要做清洗和异常检测——比如某个计划的点击率突然暴增，可能是异常流量，需要标记出来，避免干扰后续的策略判断。”
“拿到数据后开始做多维度归因分析。哪些素材的点击率高、哪些受众群体的转化好、哪些投放时段的 ROI 更优。归因结果交给策略生成 Agent，然后输出具体的优化建议，比如说'计划 A 的素材点击率低于均值，建议替换主图'或者'计划 B 在凌晨时段的转化成本过高，建议降低该时段出价'。建议要具体到哪个计划、改什么参数、改成多少。”
“接着调用广告平台的 API 执行调整。新策略先在小流量上做 A/B 测试——抽一部分预算按新策略投放，和原策略对比效果。效果达标之后灰度放量，逐步从小比例提到全量。”
“有两个关键点。第一，预算变更必须走人工审批。Agent 可以调出价、换素材、改定向，但涉及预算增减的操作，必须推送给投放同学确认后才执行。第二，止损机制。如果某个计划调整后 ROI 连续低于设定的阈值，自动暂停该计划并报警，等人工介入排查。”
“最后记得定时刷新数据，比如每小时拉取一次——重新评估当前策略的效果。效果持续好的维持不动，效果回落的触发新一轮分析和调整。”
PaiCLI 如何写到简历上？
项目名称：PaiCLI — 终端 AI Agent 命令行工具
项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、代码搜索、工具调用、自动修复等能力。
技术栈：Java 21 + Spring AI + Elasticsearch + MCP 协议
核心职责：
- 设计并实现 Agent 三模式架构，ReAct 处理日常交互、Plan-and-Execute 按依赖图分步执行复杂任务、Multi-Agent Team 让规划-执行-审查三角色协作，根据任务复杂度自动路由
- 构建双层记忆系统（长期记忆 + 短期记忆），长期记忆包含事实记忆（语义检索按需注入）和项目规范（PAI.md 全量注入），短期记忆通过两层压缩控制上下文占用，单次请求 token 成本降低约 35%
- 实现 9 层 Prompt 组装器，静态层前置命中 Prompt Caching，动态层按 token 预算裁剪
- 搭建 Agent 评测框架，集成位置平衡 A/B 评分和 LLM-as-Judge 自动化评测，结合人工校准保障迭代质量不回退
- 设计 Skills 渐进式加载体系，索引→正文→参考文档三级按需加载，通过 LRU 缓冲区控制同时激活的 Skill 数量，避免上下文溢出
ending
当你习惯通过日常学习来提高自己，就不会去想着用 AI 作弊来获得一时的便利。
因为真正的能力是靠自己日积月累换来的。
回复