如题，看到这样一则爆料。
说实话，酸了，真酸了。
能在 30 多岁没有经济压力，运气肯定不会差，并且个人实力应该也很到位。
我认识不少大厂的朋友，这两年靠着 AI 确实搞得风生水起。从他们身上我也总结了几点，大家看看是否登味十足？（笑
第一，悟性高，能很快挖掘到一个潜力点，不管是做产品还是小到对一件事的看法，都有自己的方法论。
第二，执行力强，我自认为执行力已经拉到满中满了，但和一些朋友比起来，我只能是小卷王，他们才是真卷王。
第三，忽视那些反对声音，现实生活中我们经常被别人否定，很难做到心无旁骛，但想要做成一件事，必须要保持专注，你骂归骂，我看不见听不见忽视你还不行吗。
再说说鹅厂。
今年在 Agent 赛道确实像开了挂，直接变身“Agent 超级工厂”，产品矩阵已经相当完整，基本把办公、编程、设计和系统操控全覆盖了。
WorkBuddy、Marvis、Miora、小微、大圆、元宝，这些都是能排得上号的产品。底层模型混元 Hy3 在 Agent 的干活能力上也有了质的飞跃。
如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来的硬核内容，希望你能认真读一读。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗发～）
content
01、为什么 Agent 最难的不是接入大模型？
老王翻了翻我的简历，开门见山问道：“你觉得做 Agent，最难的是什么？”
“最难的肯定不是接入大模型。”
“因为接入大模型这件事，说白了就是调 API。申请 API Key，然后弄个 SDK，让 Agent 写几行代码把请求发出去、把响应拿回来，就搞定了。”
“真正难的是大模型接进来之后的 Harness。”
Agent 要在真实环境里干活，就意味着它要操作文件、执行命令、访问数据库、调用第三方服务。
“有五件事我觉得很重要。”
“第一是权限管控。Agent 能做什么、不能做什么，必须在权限控制内。”
“第二是工具编排。Agent 调用的工具越多，工具之间的依赖关系就越复杂。哪些工具可以并行执行、哪些必须串行、失败了怎么回滚、超时了怎么处理，需要一套完整的调度机制。”
“第三是错误恢复。模型会有幻觉，工具会超时，网络会中断，进程会挂掉。生产级的 Agent 必须能处理这些异常。”
“第四是上下文管理。模型的上下文窗口是有限的，Agent 在长任务中会不断积累对话历史、工具调用结果、中间产物。怎么在有限的窗口里保留最关键的信息，什么时候压缩、什么时候直接扔掉，很影响 Agent 的交付质量。”
“第五是审计追踪。企业环境里，Agent 做了什么必须可追溯。谁触发的、调了什么工具、传了什么参数、结果是什么，出了问题能回溯。”
02、用 WorkBuddy 总结腾讯文档，怎么判断员工有没有读取权限？
老王用左手食指推了推眼镜，继续问：“用过 WorkBuddy 吗？假设一个员工让 WorkBuddy 总结一份腾讯文档，Agent 怎么判断这个员工有没有读取权限？”
“核心就一条——Agent 不能用自己的身份去访问资源，必须用员工的身份。”
“员工通过微信登录之后会拿到一个用户令牌（User Token），代表这个员工的身份和权限。WorkBuddy 需要做一个统一身份管理，所有 Agent 请求都携带这个身份信息。Agent 调用腾讯文档的 MCP Server 时，请求里必须带上用户令牌。”
“MCP Server 收到请求后，拿着用户令牌去腾讯文档的权限系统做校验——这个员工对这份文档有没有读取权限。有，返回文档内容。没有，返回权限不足的错误，Agent 告诉员工‘你没有权限查看这份文档’。”
“不管校验通过还是失败，这次访问都要记录下来——谁在什么时候尝试读取了哪份文档，结果是什么。”
03、终端 Agent 升级成桌面级 Agent 怎么做？
老王低头看了一下我简历上的 PaiCLI 项目，继续问：“PaiCLI 已经是一个不错的终端 Agent 了。如果让你升级成 WorkBuddy 这样的桌面级 Agent，你打算怎么做？”
PaiCLI Agent 已经开源到GitHub，Python、Go、Java、TypeScript版本都有：https://github.com/itwanger/PaiCLI-Python
“第一是交互层。PaiCLI 现在是纯文本交互，用户在终端里输入指令，Agent 用文字回复。桌面 Agent 需要 GUI，用户可以点击、拖拽、选择文件、查看图片。交互从单一的文本变成了文本加图形，甚至还有语音。”
“第二是工具集。PaiCLI 的核心工具是面向开发场景的——读写文件、执行命令、代码搜索。桌面 Agent 需要一套完全不同的系统级工具：剪贴板读写、应用间通信、文件管理器操作、日历和邮件访问、截屏和 OCR。”
“第三是常驻后台。PaiCLI 是按需启动的，用完就退出。桌面 Agent 需要作为守护进程常驻后台，随时响应用户唤起。涉及到进程管理、资源占用控制、心跳检测这些问题。”
04、如何设计 Agent 的完整审计记录？
“审计要记录：谁做的、做了什么、什么时候做的、为什么做、结果是什么。”
“PaiCLI 已经实现了一套审计系统。”
每一条审计记录包含这些字段：时间戳、工具名称、工具参数、执行结果（通过、拒绝还是报错）、审批来源（用户手动批准的还是策略自动允许的）、执行耗时。
“工具参数会做截断和脱敏。参数里如果包含 Bearer Token、API Key、密码这些敏感信息，写入之前用正则匹配替换掉。”
“存储格式用 JSONL——每条记录是独立的一行 JSON，追加写入。好处是写入性能高，不怕写入中断导致文件损坏。日志按天轮转，文件名带日期。审计目录的权限设置成只有当前用户可读写，防止其他进程篡改。”
05、Agent 重复调用工具时如何避免重复副作用？
“幂等。”
“每次工具调用生成一个唯一标识，由工具名加关键参数的哈希组成。执行前先查执行记录，同一个幂等键已经执行成功过，直接返回上次的结果，不重复执行。”
“写文件用覆盖写入而不是追加写入，创建资源前先检查是否已存在。”
“如果 Agent 连续多轮调用同一个工具、传入相同的参数，说明模型可能陷入了死循环。PaiCLI 有一个停滞检测机制——连续 3 轮相同的工具调用会触发退出，避免无意义的重复。”
幂等键怎么设计才不会误判？
“关键是选对参与哈希的参数。”
“不是所有参数都应该参与。比如执行命令的工具，命令内容应该参与，但时间戳不应该参与。写文件的工具，文件路径和文件内容都应该参与。”
“还有一个时间窗口的问题。同一个幂等键在 5 分钟前执行过，现在再执行一次，算重复还是新的任务？Agent 可以追问一下用户的意图。”
06、Agent 的长任务如何保证进程重启后继续执行？
“靠检查点（Checkpoint）。”
PaiCLI 有一个持久化的任务管理模块，用 SQLite 做任务存储。每个任务有一个状态机：排队中 → 执行中 → 完成或失败。任务的当前状态、输入参数、已完成的步骤、中间结果，都存在 SQLite 里。
“进程启动时，任务管理模块会扫描所有状态为‘执行中’的任务——这些就是上次进程退出时还没跑完的，把它们重新放入执行队列继续。”
一个长任务可能包含几十个步骤。任务级恢复，进程挂了整个任务要从头开始。步骤级检查点，每完成一个步骤就把状态写入存储，恢复时从最后一个成功的步骤继续，已完成的步骤不重新执行。
07、Agent 调用模型或工具失败后什么时候可以重试？
“区分可重试和不可重试两类错误。”
“可重试的：HTTP 429 限流、500/502/503/504 服务端错误、网络超时、连接被重置。这些属于临时性故障，过一会儿再试很可能就好了。”
“不可重试的：401 认证失败、400 参数错误、SSL 错误、JSON 解析失败。这些是确定性错误，重试多少次结果都一样。”
PaiCLI 的重试模块实现了一套完整的机制。默认 3 次尝试，退避策略是指数退避加抖动——基础延迟 500 毫秒，每次翻倍，上限 30 秒，再加上正负 20% 的随机抖动。
“抖动是必须的。如果多个 Agent 同时触发限流，同时等待相同的时间后重试，所有请求就会在同一时刻涌入，又被限流，又等待。抖动让每个 Agent 的重试时间错开，打散请求峰值。”
“如果服务端返回了 Retry-After，优先用服务端的等待时间。”
如果模型调用是流式的（SSE），Agent 已经把部分输出展示给用户了，这时候连接断了，能不能重试？
不能。
因为重试意味着模型重新生成，新的输出和已展示的部分会不一致。PaiCLI 的做法是：流式响应已经有内容被消费了，就标记为不可重试。
场景题
08、Agent 如何在效果、延迟和成本之间进行模型路由？
老王摘下眼镜用他的格子衫擦了擦，又重新带上，继续问：“WorkBuddy 里可以配置混元、DeepSeek 这些模型。如果让 Agent 自主选择模型，应该怎么发挥每个模型的长处？”
“分两步：先做任务分级，再做模型匹配。”
“简单任务，比如说格式转换、信息提取、短文本摘要，对推理能力要求不高，用快速便宜的模型就够了。复杂任务，比如说代码生成、多步推理、长文档分析，需要强推理能力，用更大尺寸的模型。”
“分级可以用一个轻量级的分类器做，甚至可以用规则。比如输入长度短、不包含代码块、不包含‘分析’、‘比较’、‘设计’、‘深度调研’这类关键词的，大概率是简单任务。”
“模型匹配是给每个模型建一张能力画像。混元 Hy3 擅长中文理解和工具调用，Agent 场景下的 SkillsBench 得分有 55。DeepSeek V4 擅长代码生成和数学推理，成本相对低。”
当然也可以手动切换——用户通过命令选择模型，系统在运行时创建新的客户端实例，对话历史保留，上下文管理策略根据新模型的窗口大小自动调整。
“但理想的自动路由应该是。”
“第一，前置意图分类器。在主模型调用之前，用一个轻量模型快速判断任务类型和难度。”
“第二，动态降级。默认用中档模型，如果返回的质量不达标，自动升级到更强的模型重试。反过来，检测到任务很简单，主动降级到便宜模型。”
“第三，成本监控。按用户、按部门统计 token 消耗和模型调用成本，超出预算自动切换到低成本模型。”
PaiCLI 的多模型架构是怎么设计的？
PaiCLI 的模型工厂支持 7 个提供商——GLM、DeepSeek、StepFun、Kimi、FreeLLMAPI、讯飞星辰 MaaS、Agnes。每个提供商有独立的客户端实现，启动时按优先级尝试连接，默认提供商连不上就自动往下重试。
“切换模型时需要注意不同模型的上下文窗口。GLM-5.2 是 256K，DeepSeek V4 是 1M。切换之后，压缩触发的阈值、保留的对话轮数、搜索结果的分块大小都要自动调整。”
09、怎么评测一个企业级 Agent 有没有真正创造价值？
“看四个维度。”
“第一是效率。Agent 接手之前，员工完成某个任务需要多长时间？Agent 接手之后呢？这个对比必须基于真实的使用数据。比如整理一份会议纪要，以前人工要花半小时，现在 Agent 几分钟搞定，就是可量化的效率提升。”
“第二是质量。Agent 完成的任务准确率怎么样？有多少需要人工修正？如果 Agent 总结的会议纪要每次都要改，效率提升就被质量问题抵消了。”
“第三是采纳率。Agent 上线了，有多少员工在主动用？用了之后还会继续用吗？日活、周留存、主动调用频率，这些数据能反映 Agent 是不是真的解决了痛点。”
“第四是 ROI（Return on Investment，投入产出比）。模型调用的成本，MCP Server 的成本，开发迭代的成本。这些加起来，和 Agent 节省的人力成本对比，到底划不划算。”
11、腾讯会议结束后，WorkBuddy 怎么完成从会议记录到任务分配的全流程？
老王无名指上的戒指轻轻碰了一下茶杯，应该是无意识的，接着问：“一场腾讯会议结束后，WorkBuddy 需要读取会议记录，提取决策和待办，查询腾讯文档补充背景，把任务分配给对应员工，并在企业微信群里发送通知。请你设计一个完整的 Agent 系统。”
“这是一个典型的事件驱动+ Agent 编排的系统。”
“腾讯会议结束时发出一个 Webhook 事件，包含会议 ID、参会人列表、会议时长。Agent 编排器监听这个事件，收到后启动工作流。”
“Agent 编排器把整个工作流拆成五个步骤，按依赖关系安排执行顺序。”
“步骤 1，调用腾讯会议的 MCP Server，拿到会议的完整记录，包括转写文本和共享的屏幕截图。”
“步骤 2，把会议记录交给 LLM，提取决策项和待办事项。每个待办包含内容描述、责任人、截止日期。输出要求是结构化的 JSON。”
“步骤 3，拿到待办之后去腾讯文档里找相关的背景资料。比如待办里提到‘更新 Q3 预算表’，Agent 需要找到这份预算表的链接，确认责任人有编辑权限。”
“步骤 4，创建任务，分配给对应的责任人。可以在企业微信里创建。”
“步骤 5，在会议关联的企业微信群里发送一条汇总通知——会议决策摘要、待办列表、每个待办的责任人和截止日期。”
“然后是 MCP Server。每个外部系统封装成独立的 MCP Server——腾讯会议的、腾讯文档的、企业微信的。每个 MCP Server 独立部署、独立鉴权，通过 MCP 协议和 Agent 通信。”
“最后是容错。长流程最怕中断。每个步骤执行完写检查点，失败了从最近的检查点恢复。通知发送失败要有重试。任务创建失败要能降级，保证信息触达。”
PaiCLI 如何写到简历上？
项目名称：PaiCLI — 终端 AI Agent 命令行工具
项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、代码搜索、工具调用、自动修复等能力。
技术栈：Java 21 + Spring AI + MCP 协议 + SQLite + Elasticsearch
核心职责：
- 设计并实现多层权限管控体系，包含用户审批、路径守卫、命令守卫等，所有写操作和 MCP 工具调用必须通过策略校验后才能执行
- 构建 JSONL 格式的审计日志系统，记录每次工具调用的时间戳、参数、结果和审批来源，并实现数据自动脱敏
- 实现基于 SQLite 的持久化任务管理模块，支持任务状态机和进程重启后的自动恢复，配合 Checkpoint 机制保障长任务的连续执行
- 设计 LLM 重试策略，区分可重试和不可重试错误，采用指数退避加抖动机制，并将流式输出已消费的响应标记为不可重试
- 实现多模型 Provider 工厂架构，支持 7 家模型提供商的运行时切换，并根据模型窗口大小自动调整压缩策略
ending
Agent 时代，需要学习的内容变多了。
但说实话，底层还是那么点东西，唯一需要我们去做的，就是给自己信心。
给自己时间。
只要你的底层的工程和思维能力具备了，题目再变，或者工作场景再变，都能轻松自如对应对。
给自己加加油，打打气，继续冲吧！
回复