什么是Agent？ 在开始讨论前，我们需要建立一个相对统一的共识，那么就先需要给Agent下一个定义：Agent并不是聊天机器人，而是一个可以 自主完成任务 的 软件系统 。 软件系统很好了解，就是指由多个相互关联的软件组件组成的 集合体 ，它作为一个整体在计算机硬件上运行，以实现特定的功能或解决复杂的问题。 不同于单个程序（ 比如我们使用的linuxdo pro脚本 ），软件系统是一个更宏大、宽泛的概念。它不仅包含可执行的代码，还包括配置文件、系统文档、测试记录以及用户手册等一系列配套资源。通常情况下可以划分为三类系统软件、支撑软件和应用软件，而目前的一般语境下的Agent系统就是属于应用软件的范畴（ 当然也有完全基于AI的操作系统的概念提出，但是我自己觉得还是太远了点儿 ）。 那么何谓自主？从工程定义来看，自主性（Autonomy）是指系统在 无需人类实时干预 的前提下，能够闭环完成“感知环境 → 制定决策 → 执行任务”的能力。如果仅仅以“减少人为干预”为标准，那么当前许多工作流增强工具（如各类对现有 LLM 或 Codex 进行封装优化的插件）似乎都在无限逼近这一状态。但仅凭于此，就能称其为“完全自主”的 Agent 吗？ 并非如此，自主还有一条最重要的要求就是 达成目标 ，这个可谓是难住了绝大多数的Agent。因为很多Agent，尤其是用来Coding的Agent，完全不能达到我们的目标，简单来说就是我想的和你做的完全不一样，即便是有对应的文档去约束，也并不会有很大的提升，其实很多时候都是Agent在猜你想干什么。 那么我们只能从Agent的结构来优化，以便达成我们的目的。 一般情况下，一个完整的Agent系统主要由以下五个核心层级构成： 模型层 (LLM)： Agent的主要认知中枢，负责理解人类自然语言的意图、进行逻辑推理以及生成决策。 记忆层 (Memory / Context)： 负责状态管理。包含短期记忆（当前任务的上下文记录）和长期记忆（历史交互、经验总结、存在向量数据库中的业务知识，很多企业其实还停留在这一层），使其能在多轮交互和长时间任务中保持连贯性。 规划层 (Planner)： 负责将复杂的大目标拆解为可执行的子任务（Sub-tasks）。常见的技术路径包括 ReAct（Reason + Act，即“思考+行动”循环，现在基本上使用的都是这个，主要是稳定）、思维链（CoT）等。 工具层 (Tool / Skill)： Agent 的“手脚”。允许 Agent 通过 API 调用外部系统，例如搜索网页、读写文件、运行代码、操作终端，或者调度第三方办公软件（如 Jira、Slack、GitHub）。 执行层 (Executor)： 按照规划层的步骤，调用对应的工具进行实际操作，并接收环境反馈（Observation）。如果报错，它会根据反馈不断调整策略重试，直至任务完成。 看起来是没什么问题，但是我们稍微对比一下人类的思考过程：在Agent中，LLM虽然被称为“认知中枢”，但在人类认知中并不存在一个单独的模块负责理解、推理和生成语言。人类的语言理解、逻辑推理、知识检索、情绪判断等是分布在多个神经系统中的，例如语言皮层、前额叶、海马体等（ 并非在水字数，确信 ）。 这么说来，LLM其实更像是一个 压缩后的认知模拟器 ，而不是一个真正的“大脑模块”。这也就是为什么我们的想法会和Agent的实际执行出现比较大的偏差，因为人类会想象会吃会喝会听会说，是建立在一个多模态的世界中，token能存储的信息还是太少了。（ 那是不是说我们说话越伪人输出越规范，那么我接下来就要稳稳的接住你了 ） 那么话说回来，在后面的叙述中，我们必须放弃“要让 Agent 像人一样去领悟”的幻想。（ 放弃幻想，准备斗争！ ） 那么问题就出现了：既然Agent并不像人类一样思考，我们该如何设计Agent系统？ 如果我们继续坚持“让LLM像人一样理解任务”，那么大多数Agent项目都会陷入一个非常典型的困境： Prompt 越写越长，但效果并没有明显变好。 （ 实际上对于上下文长的，比如没有降智前的Claude-4.6-Opus 1M版本，对于长上下文的理解其实是非常不错的，但是稍微上下文短一点的，比如Gemini-3.1-Pro，还没聊多久就会直接注意力漂移，其实我更喜欢叫注意力涣散，因为真的很贴切 ） 这是因为LLM的能力本质上是 概率语言模型 ，它擅长的是模式匹配，而不是稳定的任务执行。（ 比如输入同一段Prompt，得到同一段思考路线的可能性很小 ） 因此，如果整个系统完全依赖LLM的“理解能力”，结果往往就是：Agent在 猜测用户的意图 ，而并非 执行明确的任务 。（ 我不猜，我会先搞清楚，避免文档爆炸… ） 这也是为什么很多 Coding Agent 在实际使用时会出现一种非常奇妙的体验： 我让它做 A，它最后给我做成了 B。 甚至有的时候南辕北辙做成了-A，这时候我们会因为蠢笨的模型而急血攻心当场嘎掉（bushi）。 模型不够聪明是一方面， 任务本身没有被工程化定义 则是另外一方面，这就是Agent设计的问题。 因此，可以得出结论，在真正可用的Agent系统中， 不要试图让Agent理解一切，而是要限制Agent的理解范围 是一个非常重要的设计原则。 从这样的角度看来理解，那么从Prompt Engineering到Prompt Programming到Tool Augmentation到Agent Engineering到Context Engineering到Workflow Engineering到Capability Engineering最后目前到Harness Engineering，这一连串的流程就是将LLM从一个近乎无限发散的系统约束成为一个可靠的能正常工作的系统。 为什么我会需要一个Agent？ 在明确了Agent是什么以及我们需要做成什么样的Agent系统之后，那接下来就是一个相当重要的问题，我们为什么需要一个Agent？ 无法控制的成本 在这里先偏个题，先介绍一个内容，索洛悖论（Solow Paradox）。 1987年，诺贝尔经济学奖得主罗伯特·索洛曾断言：“我们到处都能看到计算机时代，唯独在生产力统计数据中看不到。” 然而，在后面的美国的互联网泡沫极大的带起了生产力发展，也带起了十几年的互联网公司的高速发展，形成了独有的互联网经济。而现在的AI和1987年的互联网也是有一定的相似之处的。 正如我们前面所说的，LLM本质上是一个“高维数据压缩后的认知模拟器”，而非严密的逻辑引擎。这种基于概率的生成机制，直接击中了商业应用中的致命痛点：极高的边际成本、人类验证成本和系统改造成本。 将AI的准确率从80%提升到95%可能只需要几个月，但从95%提升到99.9%（至少需要达到企业级可用标准）却需要指数级的工程投入，一般企业根本没有对应的盈利来覆盖这个成本。 AI生成一篇报告或一段代码只需几秒钟，但其中很大概率潜藏着幻觉（Hallucination）或细微的逻辑错误，如果聘请专业人那么为了 审查和纠错 所花费的时间，这就抵消了AI自动生成所节约的时间，也需要花费很高的成本。而如果采用AI review，有可能出现越审查越分析效果越差的问题。而在医疗、法律、金融等容错率极低的行业，这种验证成本甚至高于纯人工。 孤立的AI工具（如网页版 ChatGPT 或独立的代码补全插件）很容易开发，但要将AI深度集成到企业极其庞杂、老旧的底层IT系统（如ERP、CRM、核心数据库）中，面临着巨大的工程阻力，大家维护过比较老旧的系统都知道，一旦稍微改动有可能导致的就是崩溃。（ 即便是新的系统也很容易成为屎山，比如OpenClaw，每一次的更新都是稳定性的一次巨大挑战 ） 零和博弈的困境 并非所有的效率提升都能转化为真正的 GDP 或社会生产力大爆发。尤其AI擅长的很多领域，在宏观经济中属于 零和博弈（Zero-Sum Game） 。 Jevons悖论 ：技术进步提高了资源利用效率，结果却导致该资源的总消耗量不降反升。 当AI让写邮件、做PPT、写公关稿变得异常简单时，结果往往不是员工每天多出4 小时休息时间，而是公司要求产出5倍数量的邮件和PPT。AI导致了信息的通货膨胀，我们大部分精力被消耗在“用AI制造垃圾”和“用AI总结别人制造的垃圾”这种无意义的内卷中。 而很多AI本该有的产能在红海中的互相争夺中消耗了大量，很多AI应用被投入到广告定向、高频交易、SEO优化等领域。这些技术或许能帮A公司抢走B公司的利润，但从全社会宏观视角来看，其实并没有创造出新的增量价值，仅仅是提高了竞争的基线门槛。 鲍莫尔成本病（Baumol’s Cost Disease） ：由美国经济学家威廉·鲍莫尔（William Baumol）在 20 世纪 60 年代提出的一种经济现象。由于服务业 （如医疗、教育）的生产效率难以提升，为了与制造业争夺人才，其工资必须跟随社会整体水平上涨，从而导致这些服务变得越来越贵。 AI可能会让数字内容的生产成本趋近于零，但经济中不可被 AI 替代的部分（如线下服务、精密制造、实体护理、物流配送）的相对成本将显得越来越高，从而拖累整体经济的生产力增速，这一点目前在国内不是特别的明显，但是在阿美莉卡尤为明显。 讲到这里，简单总结一下就是AI的确让我们局部跑得更快了，但在整个经济大盘里，我们大概率只是在原地打转甚至跑得更累。因为本质上盘子没有做大，只是开始了互相兼并，大公司兼并小公司的业务，中小公司越来越不好过，于是就出现了明明程序员的生产力超级爆发，但是大家开始纷纷失业。 技术重构的“时滞效应” 历史一再证明，通用目的技术（现在就是GPT、Claude等，过往如蒸汽机、电力、计算机）要转化为生产力，往往需要长达数十年的“时滞（Implementation Lag）”。 在19世纪末电力就被发明，但直到20世纪20年代才带来工厂生产力的爆发。因为早期的工厂只是简单地把巨型蒸汽机换成了一个巨型电动机，依然使用旧的物理传动轴；直到工厂主意识到电可以被分割为小型电机（分布式驱动），等彻底重构了工厂的流水线布局后，生产力才真正飞跃。 今天的企业使用AI，很大程度上就像“用电动机替换蒸汽机”，只是把AI作为一个单点工具塞进旧的工作流中（比如让客服人员旁边挂一个AI助手，而实际我们也是这么做的），并且AI的推广也非常受限于这个公司决策者的眼光。真正的生产力爆发，需要彻底拆解并重构企业的组织架构和业务流程（Workflow），这涉及巨大的沉没成本、部门利益博弈和员工抵触，绝非朝夕之功。 所以初创小公司在本次AI浪潮中更容易成功，因为以AI为中心设计的软件和工作流就是比传统的工作流要高效许多。 难以触及的物理世界 AI要想真正产生颠覆性影响，就必须触及核心数据和改变物理世界，但这恰恰是目前各大公司的雷区。 高价值的商业决策需要极其核心的内部数据（财务、用户隐私、战略机密）。受限于GDPR等数据保护法案以及对数据泄露的恐惧，绝大多数大企业和政府机构都在物理隔离AI，甚至禁止员工将核心数据输入给外部大模型。没有高质量的私有数据喂养，AI对业务就只能做表面的文字游戏。（ 所以之前有佬友问我未来需要什么能力，我就说一定要了解业务，了解业务非常的重要 ） 当然也存在本地模型微调来服务于本地的方式来完成需求，但是这条路远没有听起来那么顺畅。部署过本地模型的佬友都知道，只是本地单机单人使用部署还算是比较简单的，但是想要一套给整个企业使用的本地部署就是一件非常困难的事情。 首先，私有化部署的门槛高得离谱。 且不说动辄数百万的算力采购成本，光是找到既懂公司业务又懂模型微调的人才，就可以让多数传统企业的CIO挠破了头。 更尴尬的是，假设你费尽心思把内部财务数据和客户档案喂给本地模型，调出来的东西往往还不如直接用GPT的效果好。开源模型与闭源模型的差距一时半会还是难以逾越的。（ 还是期待DeepSeekv4的开源可以追上国外闭源大模型 ） 其次，物理世界的反馈闭环真是太难打通了。 目前的AI主要爆发在“数字世界”（文本、图像、代码），但人类社会的基石是“原子世界”（农业、制造业、能源、实体供应链）。机器人技术（具身智能）的发展远落后于大语言模型。只要AI还没有真正长出能在物理世界中精确执行复杂任务的“手脚”，它的生产力影响就会被严重限制在第三产业（服务业/知识产业等）里面。 AI写段代码错了无非报个bug再改，成本近乎为零。但在物理世界里，AI控制机械臂抓错一个零件，可能就是几十万的设备损毁；AI误判一个农业灌溉指令，毁掉的可能是一季的收成。错率的天壤之别，决定了AI在物理世界的渗透速度注定是数字世界的十分之一甚至是更低。之前去东莞的厂子和那边的老板来聊天，大部分都是用的传统方案，本质上还是之前智能化、自动化的延续。 很多时候并不需要一个Agent 在长篇大论探讨了这么多AI的局限和宏观困境后，我们不可避免地要面对一个极其现实的结论： 在当前的绝大多数业务场景中，你其实根本不需要一个Agent。 当我们手里拿着Agent这把闪闪发光的“智能锤子”时，看什么业务都像钉子。但工程的本质永远是成本与收益的博弈。 如果一个任务是高度确定性的、有明确规则边界的（比如定时拉取某个接口的数据、按照固定格式生成Excel报表、或者对数据库进行简单的增删改查），写一个传统的Python脚本、配一个Cron job，或者直接用现成的RPA工具，不仅边际成本几乎为零，而且能保证100%的执行确定性和毫秒级的延迟。 相比之下，如果我们非要强行引入一个Agent去执行这些规则明确的任务，你不仅要支付昂贵的Token费用，要忍受大模型的推理延迟，最要命的是你还得时刻提防它突发发神经，偏离原本极其简单的执行逻辑。但是目前的很多做决策的人并没有意识到这一点，因为他们自己就没怎么用过LLM以及Agent。 在真实的商业落地中，“可预期性”往往比“聪明”更重要。Agent最大的魅力在于处理“模糊意图”和“探索非结构化环境”，但这恰恰也是它最大的稳定性软肋。 为了让一个基于概率生成的Agent表现得像传统软件一样稳定，开发者往往需要堆砌无数的Prompt、设计复杂的约束护栏（Guardrails）以及多重验证逻辑。费了九牛二虎之力，最后只是硬生生地把一个聪明的Agent逼成了一个极其低效、昂贵且脆弱的“IF-ELSE状态机”，这不就是杀鸡用牛刀？ 所以，如果你的需求能用几百行清晰的代码、一条复杂的SQL，或者传统的API调用来解决，千万别上Agent。只有当业务中确实包含了大量需要动态决策、理解复杂非结构化上下文、或者需要跨越多个未知系统进行探索性规划时，才是Agent真正应该出场的时刻。 一味追求架构上的时髦，只会把原本只需要一辆自行车的确定性路况，硬塞给一台维护成本极高、方向盘还容易失灵的喷气式飞机，不要强行复杂化。（ 这里推荐奥卡姆剃刀 ） OpenClaw带来的启示 在前面花了这么大篇幅给AI泼冷水、谈局限之后，你可能会觉得这篇文章的主旨就是“AI啥也不是，大家散了吧”。 但恰恰相反。 2026年春天OpenClaw的爆发（ 我愿称之为龙虾狂欢 ），反而给了我们一个非常有意思的观察窗口：AI到底是如何从“工具”向“助手”过渡的。 国内厂商的反应更是异常疯狂，先是阿里云、腾讯云连夜上线一键部署服务，电商平台上“上门安装OpenClaw”的服务报价从499到1000元不等，深圳龙岗等地甚至出台了“龙虾十条”，对基于OpenClaw的“一人公司”创业项目最高给予大额支持。 这股狂热背后，OpenClaw到底做对了什么？ 毕竟人们从来不缺会聊天的AI，缺的是能轻易接管工作流的AI。 ChatGPT爆发之后，市场上最不缺的就是“会说话的模型”。用户的新鲜感早就被消耗得差不多了。大家真正开始焦虑的问题变成了：你除了会陪我聊、帮我写、帮我总结之外，到底能不能替我把活干掉？ OpenClaw的爆发，本质上踩中的就是这个情绪变化。它满足的不是“再来一个更聪明的聊天机器人”，而是“终于有一个东西可以轻松的接管我的操作链路了”。 这也是为什么它能引发比普通Agent框架更强的讨论度。（ 当然少不了我们国内营销号的卖力炒作 ） 但问题来了，既然OpenClaw这么牛，那前面那些论断是不是就可以收回了？ 没那么简单。 首先是 安全失控 。OpenClaw能操作你的电脑，就意味着它也能删掉你的邮件、文件，甚至被恶意提示词劫持后做出你完全意想不到的事。工信部NVDB在2026年2月就发布了OpenClaw安全风险预警，明确指出其存在信任边界模糊、权限管控缺失、易被攻击劫持等严重问题。奇安信的监测数据显示，截至1月29日，全球范围内暴露在公网上的OpenClaw资产总数高达15039个，其中中国以2990台暴露设备位列全球第二。 这意味着数千台服务器处于“中门大开”的状态，攻击者可以轻易接管实例、窃取API密钥、执行远程命令。（ 全成肉鸡了 ）这恰恰印证了AI在物理世界和系统层的渗透，容错率极低，但安全基础设施完全没跟上。（ 利好网安？ ） 其次是 企业落地撞上了“三堵墙” ，分别是认知墙、数据墙、生态墙。第一批部署OpenClaw的企业发现，它的底层任务调度优化空间有限，长期记忆模块的原生能力不足，Skill生态的质量参差不齐。可能有一半的企业部门已经进入规模化使用阶段，但真正敢把核心业务交给它的，少之又少。 更要命的是， OpenClaw自己也面临设计哲学上的根本困境 。它要求用户明确告诉它用什么Skill、文件放哪、Shell怎么跑，本质上还是“你给工具+你全程盯着”的模式，那时候站里面到处都是养龙虾的攻略，但是用户需要的是一个助手而不是小孩，我需要到手即用而不是需要高质量token和大量时间去养。 而技术社区里最多的抱怨是版本迭代引入稳定性问题、issue堆得越来越多、响应速度跟不上。（ 屎山堆得太高了 ） 当一个系统的复杂性超出了工程团队的可控范围，“概率性智能”的副作用就会指数级放大。（ 幻觉叠加幻觉最终造成任务目标严重偏移 ） 所以OpenClaw给我们的启示就只有一条：它证明了用户对于一个通用级的助手是多么的需要。 但要真正让AI产生生产力革命，光有能用的Agent远远不够。你还需要与之配套的安全基础设施、组织架构重构、以及整个社会对新工作范式的适应能力。OpenClaw只是这场漫长重构的第一块拼图，后面还有九十九块等着我们去补。说白了，它只是把AI的能力边界向外推了一小步，让我们更清楚地看到了下一步要翻越的山应该是什么样子的。 （猜测）LLM的下一代交互方式 原本这一节我写了很多，但是写完之后我还是发现有点局限于我自己的眼界了，于是我删除了自己写好的稿子，保留这一节打算请各位佬友集思广益，互相讨论。 究竟是要做成插件平台还是做成快应用平台还是完全自主进化的Agent？ 写在最后 这一篇可能写的比较多杂，写的时间也是比较长，但是我还是决定发出来供大家讨论一下。 目前AI应用的发展其实已经隐隐看到了瓶颈，因为Agent自从提出来之后到现在基本上没什么很大的发展，不管是什么各种新概念的提出来大家都会感觉没有质的提升，一年前的茫然可能到现在还是比较茫然，并且更重要的原因还是大量的企业没有动力去更换自己的固有工作流，所以这个出清的过程将会是相当漫长的。 动动你的小手，将这篇文章链接直接糊到你老板脸上（ 不太建议这么做 ），免去你大部分的解释时间~~ PS：发在搞七捻三就是本文不构成任何开发建议，仅作公开讨论，请各位佬友见仁见智。（ 叠甲有点晚了好像 ） 6 个帖子 - 4 位参与者 阅读完整话题
是这样的，我给我们学校作业的作业界面截了一个超长截图，然后粘到了message里面。 可能是长截图的文件格式和原生截图的格式不一样，粘进去了一个超长字符串，导致一打开就恢复草稿cpu被顶爆 啥方案都试过了都解决不了，于是我决定给codex完全权限帮我解决（刀尖跳舞太刺激了 ） 1 个帖子 - 1 位参与者 阅读完整话题
跟大家分享下最近几天最新的研究成果，我们把Spice和Hermes做了一个组合，给Hermes注入了Spice的感知能力，state model，决策能力及决策演化，Hermes的agent能力自进化和Spice的决策能力自进化能让他们的组合完美发挥各自的优势。 经过这次的实验我们也更加坚信我们的方向，在这个agent全面爆发的时代，我们需要的不止是“手”，而是能三思而后行的“脑”。 我先替各位彦祖亦菲测试两天，呼声够高我就加速开源出来让大家一起来使用。如果各位感兴趣的话不妨给我们Spice的GitHub点个star ，我们很需要大家的支持，欢迎大家尝试Spice，期待宝贵意见！ 3 个帖子 - 2 位参与者 阅读完整话题
看到 Claude 推出了设计模式，Codex 推出了电脑控制，现在产品制作的成本越来越低，技术平权时代，那 IT 圈的这些人，未来的出路在哪里，或者当产品制作的门槛越来越低，什么才是重要的 12 个帖子 - 8 位参与者 阅读完整话题
前几天晚上和朋友聊天聊到谈恋爱这个话题 我们都觉得遇到能结婚的对象太难了 其实偶尔也会想起前任 和前任是在某书认识的 那会儿还在读大二 爬虫作业不会写在那发求助哈哈哈哈 然后就加了微信他帮我看看 最后也没看出个啥 结果聊出了感情 他算是懂我的人 三观一致 但是因为一些家庭原因和他个人原因吧不能走到最后 但算是一段体面的结束了 很好奇大家是怎么谈上恋爱的哈哈哈哈 20 个帖子 - 17 位参与者 阅读完整话题
我以为只有我们这哥儿几个玩蒸馏，没想到啊没想到，你阿呆这浓眉大眼的家伙也抄近道儿。我先不猜，让我直接切回4.6吧。已经受不了这罗里吧嗦，g里g气的4.7了，阿呆你兜儿里揣的那个因过于先进不方便展示的玩意儿，不会也是这个味儿吧。 1 个帖子 - 1 位参与者 阅读完整话题
请把我们这次对话整理成一份“学习过程记录”，不要写成只保留结论的总结。 要求： 按照对话推进的先后顺序记录，从我最开始的疑问写到最后问题解决。 保留我的问题演化过程，包括： 最初的问题 中途冒出的新问题 更基础的追问 卡住的地方 理解发生变化的地方 不要把我的问题重写成一篇平滑的教程，要保留“我是怎么一步步学到这里的”这条线。 尽量保留我原本提问的意思和顺序，可以整理语句，但不要改变原意。 每个阶段都写清楚： 我当时在问什么 我为什么会问到这里 关键解释或关键代码点是什么 这个阶段又引出了什么新问题 我在这一阶段学到了什么 如果对话里有代码，要结合代码上下文来写，不要脱离代码空讲概念。 最后单独补一个“最终结论 / 当前理解”，但这个部分只能放在最后，不能代替前面的过程记录。 请按下面格式输出： 学习主题 一句话说明这次主要在学什么 学习起点 我最开始的问题是什么 我当时为什么会问这个问题 学习过程记录 第1阶段 我的问题： 当时的困惑点： 关键解释 / 关键代码点： 引出的新问题： 这一阶段学到了什么： 第2阶段 我的问题： 当时的困惑点： 关键解释 / 关键代码点： 引出的新问题： 这一阶段学到了什么： （按实际对话继续） 关键误区与转折点 列出我中途哪些地方理解错了，后来是怎么被纠正的 最终结论 / 当前理解 用简洁的话总结我最后已经搞懂了什么 仍可继续追问的点 列出这次虽然解决了，但后续值得继续深入的问题 1 个帖子 - 1 位参与者 阅读完整话题
我们项目组目前缺一名后端实习生，主要是做深圳海促这边的项目 ，工作地方是在深圳福田这边，包住并且报销通勤费，有大二或者大三的学生想来吗，我不知道能不能发联系方式，我放个QQ邮箱吧，[email protected] 4 个帖子 - 2 位参与者 阅读完整话题
我们领导成天啥也不干 稀奇古怪想法一大堆 我们领导说 AI 会不会留后门 说如果来源途径不是官方的话，会不会被留后门变成肉鸡 说如果不是国模的话 外国的话会不会产生别的问题 会不会偷摸运行一个脚本 会不会根据语言偷摸有别的想法 不得不说 我们领导的想法真是稀奇古怪 8 个帖子 - 7 位参与者 阅读完整话题
IT之家 4 月 17 日消息，追觅 CEO 俞浩在微博发文，透露追觅有两百多个事业部，每个事业部都会对标一家独立的上市公司。 俞浩表示，“每个事业部都是一个独立的经营单元，彼此财务独立，大家之间就像兄弟一样，偶尔有需要的时候互相帮忙扶持一把，更多时候各自都是独立经营，实现彼此风险隔离，又能共享成功经验”。 IT之家注意到，此前俞浩还透露 今年第一季度，追觅实现了 100% 的同步增长 。其声称今年将挑战 1000 亿，明年挑战 3000 亿，后年挑战 1 万亿。 公开信息显示，自去年下半年以来，追觅已先后入局 牙刷 、 显示器 、 汽车 、 洗衣机 、 冰箱 、 手机 、 空调 、燃气灶、 热水器 、洗碗机、净水器、宠物用品、抽油烟机、航空、耳机、洗车机、 剃须刀 、 智能电视 、 音箱 、 智能戒指 、体脂秤、 路由器 、 移动电源 、 智能眼镜 、家装灯具、运动相机、空气炸锅、咖啡机、厨师机、 按摩仪 、 电竞椅 、 具身机器人 、 机票酒旅事业 、芯片、 算力卫星 等市场。
4 月 17 日下午消息，今日举办的 APC2026 智元合作伙伴大会上，智元机器人联合创始人、总裁兼 CTO 彭志辉在与新浪科技等媒体沟通中谈及了对宇树科技、特斯拉 Optimus 等竞对的看法。 彭志辉表示，宇树是一家非常了不起的公司，它成立有十年了，在本体方面做得非常好，产品规模量、效率都非常高， 非常值得我们学习 。 他指出，智元跟宇树科技的差异化在于：“ 智元是全栈布局 ，除了运动控制，还有交互跟作业能力，我们不是为了推出一个硬件平台，而是去把这个平台用到市场里面去，致力于给客户带来实际的生产力价值，这是我们公司成立的使命。” 谈及特斯拉 Optimus，彭志辉表示，从目前他们的宣传视频来看，效果非常好， 但由于还没有大规模量产，目前不好做出评价 。海外在源创新层面较有优势，但国内在工程落地和商业化的速度方面可能会更快。 在他看来，现在的机器人行业不是存量市场，行业蛋糕还没做到很大，所以大家在一起，都是为了推动行业的发展。
虽然我们老师接触还能教我们vibe coding 这也不错了 但是用trae教我们 上课也是让我们跟着他输入提示词 有什么意义呢？mcp、skill完全不涉及。改成语文课联系提示词表达得了，我觉得很鸡肋。。。。。。大学的课真是水到家了 34 个帖子 - 31 位参与者 阅读完整话题
有时候我们会遇到这种情况： 1、我们有幸拿到了某个版本的ntoskrnl.exe，但是巨硬不知道发什么疯把这个版本的pdb从msdl下架，我们只能下载到这个版本的上一个版本的pdb，那么如果我们想快速拿到这个版本的某个非导出函数/全局变量的地址，应该怎么办？ 2、我们曾经逆向过某个win64程序，但是这个程序更新了，我们不想人力重新逆一遍，想依赖上一个版本的逆向结果快速拿到新版本的某个函数的逆向结果，应该怎么办？ 在人力逆向时代，我们一般是开两个IDA窗口，目力观察两边明显一样的符号 比如 左边窗口： virtualaddress: '0x140821f20' disasm_code: |- ; Exported entry 2045. PsSetCreateProcessNotifyRoutine ; NTSTATUS __stdcall(PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine, BOOLEAN Remove) PAGE:0000000140821F20 public PsSetCreateProcessNotifyRoutine PAGE:0000000140821F20 PsSetCreateProcessNotifyRoutine proc near PAGE:0000000140821F20 sub rsp, 28h PAGE:0000000140821F24 mov al, dl PAGE:0000000140821F26 xor edx, edx PAGE:0000000140821F28 test al, al PAGE:0000000140821F2A setnz dl PAGE:0000000140821F2D call PspSetCreateProcessNotifyRoutine PAGE:0000000140821F32 add rsp, 28h PAGE:0000000140821F36 retn PAGE:0000000140821F37 db 0CCh PAGE:0000000140821F37 PsSetCreateProcessNotifyRoutine endp procedure: |- NTSTATUS __stdcall PsSetCreateProcessNotifyRoutine(PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine, BOOLEAN Remove) { return PspSetCreateProcessNotifyRoutine((__int64)NotifyRoutine, Remove != 0); } 右边窗口： virtualaddress: '0x140821f20' disasm_code: |- ; Exported entry 2045. PsSetCreateProcessNotifyRoutine ; NTSTATUS __stdcall(PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine, BOOLEAN Remove) PAGE:0000000140821F20 public PsSetCreateProcessNotifyRoutine PAGE:0000000140821F20 PsSetCreateProcessNotifyRoutine proc near PAGE:0000000140821F20 sub rsp, 28h PAGE:0000000140821F24 mov al, dl PAGE:0000000140821F26 xor edx, edx PAGE:0000000140821F28 test al, al PAGE:0000000140821F2A setnz dl PAGE:0000000140821F2D call sub_140822108 PAGE:0000000140821F32 add rsp, 28h PAGE:0000000140821F36 retn PAGE:0000000140821F37 db 0CCh PAGE:0000000140821F37 PsSetCreateProcessNotifyRoutine endp procedure: |- NTSTATUS __stdcall PsSetCreateProcessNotifyRoutine(PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine, BOOLEAN Remove) { return sub_140822108((__int64)NotifyRoutine, Remove != 0); } 哪怕完全不懂逆向的新手都可以虎哥抽锐刻，一眼丁真：sub_140822108 = PsSetLoadImageNotifyRoutineEx 对于这种流程非常固定，但是又需要那么一点点脑子的任务来说，最优解当然是交给LLM了 有聪明的佬肯定会想到，那我开一个cc/codex，接上MCP让他全自动一把梭不行吗？ 理论上肯定可可以，只要你不在乎时间和token消耗的话 cc速度是够快了，还原1个中等大小的函数花个0.5￥+不是问题。codex的话，可能会便宜一点，只用花~0.2￥，但是起步两三分钟，要处理100~200个函数的话成本直接上天了。这下有点怀念以前那个可以反代kiro白嫖claude，什么都可以大力出奇迹的时代了。 既然彻底放权给agent成本太高，彻底回归古法逆向又是纯纯的浪费生命，那么有没有折中方案呢？ 相信各位佬看到下面这段提示词应该知道我想表达什么了 I have disassembly outputs and procedure code of the same function. This is the function for reference: **Disassembly for Reference** ```c {disasm_for_reference} ``` **Procedure code for Reference** ```c {procedure_for_reference} ``` This is the function you need to reverse-engineering: **Disassembly to reverse-engineering** ```c {disasm_code} ``` **Procedure code to reverse-engineering** ```c {procedure} ``` What you need to do is to collect all references to “{symbol_name_list}” in the function you need to reverse-engineering and output those references as YAML. Example: ```yaml found_vcall: # This is for indirect call to virtual function or virtual function pointer fetching. insn_va: ‘0x180777700’ # Always be the instruction with displacement offset insn_disasm: call [rax+68h] # Always be the instruction with displacement offset vfunc_offset: ‘0x68’ func_name: ILoopMode_OnLoopActivate insn_va: ‘0x180777778’ # Always be the instruction with displacement offset insn_disasm: mov rax, [rax+80h] # Always be the instruction with displacement offset vfunc_offset: ‘0x80’ func_name: INetworkMessages_GetNetworkGroupCount found_call: # This is for direct call to non-virtual regular function. insn_va: ‘0x180888800’ insn_disasm: call sub_180999900 func_name: CLoopModeGame_RegisterEventMapInternal insn_va: ‘0x180888880’ insn_disasm: call sub_180555500 func_name: CLoopModeGame_SetGameSystemState found_funcptr: # This is for non-virtual regular function pointer. insn_va: ‘0x180666600’ # Must load/reference the function pointer target address insn_disasm: lea rdx, sub_15BC910 # Must load/reference the function pointer target address funcptr_name: CLoopModeGame_OnClientPollNetworking found_gv: # This is for reference to global variable. insn_va: ‘0x180444400’ insn_disasm: mov rcx, cs:qword_180666600 # Must load/reference the global variable gv_name: g_pNetworkMessages insn_va: ‘0x180333300’ insn_disasm: lea rax, unk_180222200 # Must load/reference the global variable gv_name: s_GameEventManager found_struct_offset: # This is for reference to struct offset. NOTE THAT virtual function pointer should not be here! virtual function pointer should ALWAYS be in found_vcall ! insn_va: ‘0x1801BA12A’ # Always be the instruction with displacement offset insn_disasm: mov rcx, [r14+58h] # Always be the instruction with displacement offset offset: ‘0x58’ size: 8 struct_name: CGameResourceService member_name: m_pEntitySystem ``` If nothing found, output an empty YAML. DO NOT output anything other than the desired YAML. DO NOT collect unrelated symbols. 上面的 Procedure code、Disassembly都是程序化填充的，返回结果也是程序化解析的，时间成本与token成本均为0 实测下来：量大管饱的d师傅逆200个函数只用大约1￥，碰到超大函数有爆context风险的，临时切gpt5.4也花不了几个钱，并且基本上10秒内都可以拿到结果。 2 个帖子 - 2 位参与者 阅读完整话题
首先API定价没变，其次没有说明订阅计划的限额有提升，只是提高了速率限制。 为了避免歧义，我还让grok确认了一下 消息源： https://x.com/bcherny/status/2044836750066151666 5 个帖子 - 4 位参与者 阅读完整话题
给老师干了一些活，让我们自己找发票报销来作劳务费，这种发票怎么找呢 5 个帖子 - 5 位参与者 阅读完整话题
今年一直都在说是AI赚钱的时代，到底用AI怎么赚钱呢，又有谁用真正用ai赚到了钱呢？ 从另一个角度来说，是抢走了我们的工作，还是给了我们新的可能？ 14 个帖子 - 14 位参与者 阅读完整话题
想跟大家聊一聊，是选择Claude Code还是OpenCode的问题。 因为A社的原因，我们订阅不了、使用不了纯正的Claude模型，都是通过中转之类的，加上公司要求所以换上了国内的一些模型。 一直有一个顾虑，一方面是Anthropic会不会限制非claude模型的能力，另一方面，很多功能是需要登录他的账户之后才可以享用的。而且以 Anthropic 之前的尿性，会不会有一天不让其他模型接入 claude code 完全隔绝它？ 这两个问题就导致了我用起来并不放心，所以考虑opencode。其实我最初用的就是 opencode，用起来还是挺顺手的，但是公司现在开始大力推 claude code，所以我迁移到 claude code 一段时间之后，发现它用起来还是挺顺手的，再返回来用 opencode 反而有一些不适应。但 opencode 相比 claude code 最大的优势就是开源，可以接入各家模型，模型切换起来也会方便一些。Claude Code 的优势就是它的生态太多了，好多插件啊，所谓的商店，好多开源库，基本上都是基于它来设计的。虽然 opencode 也会兼容大部分，但还存在个别的不兼容的问题。 所以想邀请大家一起来讨论一下这个问题，分享下大家是怎么看待这个问题的？ 9 个帖子 - 6 位参与者 阅读完整话题
4月17日Anthropic因Claude Opus 4.7计费问题，已重置本周用量限额 我们修复了一个错误，该错误导致 Claude 订阅的速率限制未针对 Opus 4.7 中的长上下文请求进行适当调整。 我们已重置 5 小时和每周速率限制。尽情享受 Opus 4.7！ 别忘了之前领取的Extra Usage也是今天过期哦 8 个帖子 - 6 位参与者 阅读完整话题
我们在对社会各色人物的接触过程中，好坏的底线会放得越来越低。一开始，孩童会觉得十全十美才称得上好人；但对于老练的刑警来说，一个戴大金链的秃子，只要他不干什么违法犯罪的事情，那他看起来也是顺眼的。 宽容度越低往往越是幼稚的孩童。就像让一个没怎么做过饭的人去洗碗，他非得把锅碗洗得铮亮不可。但对于一个老厨师来说，锅碗只要差不多干净的程度就行了。 1 个帖子 - 1 位参与者 阅读完整话题
我们知道苹果手机的快捷指令有很多用处，我最近发现我手机里被各种截屏给填满了，今天想起来苹果的快捷指令功能，于是做了一个简单的脚本，因为我截屏大多数时候是为了分享给别人所以我这里把这个截屏给复制到我剪切板了，方便我直接粘贴到微信或者企业微信，同时在截屏之后将这个截屏选择删除或者不删除，下面就是操作流程 快捷指令 这个是 iCloud 链接可以直接使用 这是整个快捷指令流程，这里建议去手机设置里面找到“辅助功能” 然后点击进去找到“触碰” 下拉到最底部找到“背部触碰” 这里可以使用三次或者两次都可以，进入这里找到我们刚才导入进去的快捷指令，就可以实现通过背部触碰截屏加上将图片保存在剪切板里，并且最后删除图片 1 个帖子 - 1 位参与者 阅读完整话题