很多人可能像我一样，经常想得多，做得少。但是，真相真的是“执行力太差”吗？ 不然。明明是看问题太泛，没有仔细思考过如何拆解问题。过去没有 AI，想解决问题无非靠： 1.自学 2.请教专业人士 自学的门槛和难度极高，在茫茫多的资料里迷失方向；请教专业人士往往有心理包袱——怕显得自己太无知，怕占用别人时间，甚至还要付出高昂的沟通成本。所以，很多想法最终都在“不知道第一步该干嘛”的内耗中死掉，导致问题始终得不到执行。 如果你知道，按照步骤 1、2、3、4 走，就一定能赚到钱或者拿到结果，相信没人执行力会差。所谓的“执行力低下”，本质上不是态度或意志力的问题，而是对行动路径的“认知模糊”。 很简单，大脑的本能，天生抗拒“不确定”。 当你给自己下达一个宏大且模糊的指令，比如“我要做一个自媒体账号”、“我要学好英语”或者“我要搞个副业”时，大脑的第一反应不是兴奋，而是防备。因为这个任务就像一片迷雾森林，你连第一步该迈左脚还是右脚都不清楚。 人类的大脑是追求“节能”和“确定性”的。面对模糊的目标，大脑无法预估消耗和风险，最本能的自我保护机制就是——拖延。 你以为你在懒惰，其实是你的大脑在自我保护。如果你把“做自媒体”拆解为：“今天花 10 分钟搜索 3 个同赛道的爆款标题”，这种极其精准且确定的小指令，你的大脑就不会产生任何抗拒。 AI 时代的破局，就是把“抽象难题”降维成“傻瓜式 SOP” 过去，我们拆解问题的成本太高。但 AI 的出现，彻底重塑了“执行力”的底层逻辑。 AI 最大的价值，不是直接帮你把所有活儿干完，而是充当一个零心理负担、随叫随到的“私人超级教练”： 彻底卸下心理包袱：面对 AI，你可以随心所欲地问任何极其微小、甚至看似“傻瓜”的问题，完全不用担心面子。 停止自我攻击：不要再骂自己“拖延”或“意志力薄弱”。每次卡住时，问自己：“是不是我现在面对的任务，还不够具体？” 践行“15分钟拆解法”，这是我一直践行的好习惯：任何一个步骤，只要让你感觉无从下手，或者评估需要超过 15 分钟，就说明它还不够细。继续拆，直到第一步细化到“打开软件，新建一个文档”这种无需动脑即可启动的程度。 善用 AI 做“路径倒推”：把你的终极目标交给 AI，让它扮演资深导师，帮你把抽象的远景倒推成具体的每日清单。 既然在这个时代，AI 已经完美充当了那个随叫随到、不知疲倦的“全能专家”，那么我们人类的角色，或者说我们努力的方向，也就随之发生了彻底的转变。 我们不再需要死磕如何自己掌握所有的硬核技能，而是要把精力放在更核心的事情上：如何去试探并确定这位“专家”的能力边界，以及如何无限拓展它的应用场景。 换句话说，知道 AI 能干什么、目前还不能干什么、怎样提问能让它干得更好，才是当下真正的核心竞争力。当你清晰地掌握了它的边界，你就能把它像插件一样，无缝接入到你生活和工作的每一个环节中。 这也是我做这个账号的初衷。 在这个账号里，我会持续分享我在研究和调教 AI 过程中的所见、所得、所思。我不仅会分享那些令人兴奋的成功案例和跑通的 SOP，更会真实地记录我自己踩过的坑、绕过的弯路。 我深知，在这个技术狂飙突进的时代，很多人想入局却又感到无从下手。我希望我在这里留下的实操记录，能帮助到后面想入行 AI 、或者渴望用 AI 提升自己“执行力”的朋友。如果我分享的那些踩坑经验能让你少走一点弯路，或者我的一些粗浅探索能起到“抛砖引玉”的作用，激发你找到属于自己的破局点，那么这件事情就充满了意义。 执行力的第一步是拆解，而驾驭 AI 的第一步，是从点下“关注”和“尝试”开始。我们一起在这个充满不确定性的时代里，用 AI 找回确定性。

米老师讲解的十分透彻，agent运行原理确实很简洁明了 但是工程的复杂性在于，一旦实操起来，理论的优雅性将荡然无存，现实颗粒度会好好给人上一堂课。 姑且谈谈之前碰过的几个坑： 1.循环次数有没有限制？否则陷入死循环token烧穿都不够用 2.工具之间的依赖是否有冲突？要怎么解决？ 3.如果中间步骤由模型验收，如何知道模型没偷懒？ 4.模型有没有误解工具的用法？能力够不够的上工具？ 5.流程会不会崩？崩之前调了哪些工具，看了哪个system prompt？ 当我们认为一件事情很完美的时候，现实总是会逼我们将它慢慢揉碎，直到我们认识到它更全面的样子。

claude大哥，对不起，从此以后我不再黑你了。 我宣布，Opus 5.5就是模型之神。 自从知道，你养活了一批中转站、家宽vps、Google账号商家以后，我对你产生了由衷的敬意。 伟大的Dario知道我们中国人挣钱不易，怕我们被ai取代，孜孜不倦地为我们封锁账号，同时为中转站、家宽vps、Google账号商家亲手打造了广阔的天地。我们应该由衷感谢你，Anthropic。 我真不是串，我的感情发自肺腑。

完了，感觉蹬不完，马上又有新重置

这张图的含金量还在上升

安装登录deepseek harness desktop还真的送额度了 dshdesktop.cn/dsh/

虽然现在很多Agent，如WorkBuddy，Claude Code，Codex都号称做了Harness，但实际体验下来，差别真不算小。这是因为从产品的角度来看，这些Harness的产品定位根本就不一样。 第一类，就是国内大厂做出来的harness。这些Harness的目标是要整合进并服务于超级APP，恨不得用户把所有软件都删了，只留它一个。所以它们首要解决的问题并不是模型和工具之间配合的极致优化，而是让不同的模型，像GLM、Kimi、Deepseek都能共享一套办公流程、文件操作、skills、权限，以便适配大厂开发的其他APP的工作流，让普通上班族都能轻松用上ai功能。 第二类，就是以Codex、Claude Code为例，新型大模型厂商做出来的Harness。它们没有大厂的包袱，做出来的Harness都很轻，都在工程层面为自家模型做了极佳的适配和极致的优化。这是因为它们的服务对象是全球开发者，直接面向专业市场。开发者不需要各种乱七八糟的功能，他们只需要一个工作台，能做脚本、小程序、机器人，而不需要诸如一键写汇报、一键查资料这类花里胡哨的功能。但是如果不用它们的自家模型api，就会有协议转换损耗、工具调用漏参数、上下文长度被削等问题。 第一类Harness通常支持多模型+自家Harness的组合和优化，第二类则专注于自家模型+自家Harness的组合，深度配合的能力非常恐怖。从这个角度来看，DSH或许在寻求第三类更折衷的路径：即将模型适配器、工具、Agent Loop等全做成可拆卸的插件，既支持多模型适配，又支持深度配合。不过就目前而言，DSH处于一个非常尴尬的位置——既没有第一类的傻瓜易用，也没有第二类的极致优化。不过DSH的灵活性也确实给人很大的想象空间，静观其变吧！

AI智能体周观察：技术噱头退潮，落地与风控成行业核心 统计周期：2026年9月21日00:00—9月27日22:00，对比上周同期（9.14-9.20），数据已剔除广告、置顶与重复内容。 整体盘面：总量微涨，关注点彻底转向 本周社区有效帖子共542篇，环比增长3.2%，总量波动不大，但行业注意力发生明显转向： 此前火热的语音智能体、多智能体架构热度快速退潮，讨论核心全面转向「AI能不能真正用在工作和生活里」「风险和控制权谁来把控」两大现实问题。 赛道冷热：实用赛道爆发，噱头赛道降温 本周八大核心主题更迭，两大新赛道跻身主流，热度分化显著： 增速最快：个人/电脑操作智能体（+145%）、安全与权限（+87%），是本周最受关注的方向 稳步增长：商业应用与自动化（+24%）、可靠性与生产调试（+8%）、编码智能体（+20%） 基本持平：工具与框架、记忆与上下文、成本与性能 大幅降温：语音智能体发帖量腰斩（-50%），已连续两天无新讨论；多智能体热度微薄，相关讨论被拆分到落地类赛道中 此外，「AI对工作与职业的影响」发帖量增长73%，成为新晋观察方向。 本周核心共识：从炫技到务实 行业讨论不再执着于模型品牌、架构新奇，而是聚焦落地痛点，形成了几个普遍共识： 商业自动化：不追求全流程无人，简单任务交给AI，高风险环节保留人工，用「总耗时」而非「生成速度」衡量价值 安全权限：按风险分级管控，读取、草拟可自动，付款、删除、发送必须人工确认，权限绑定任务与有效期 编码与可靠性：不相信AI自审自验，保留人工决策节点，用外部记录、回放、校验机制规避AI出错风险 记忆与成本：拒绝无效记忆堆砌，只留存验证过的有效信息；不盲目追求低价模型，以最终任务成功率算性价比 最后总结 热词变化也印证了行业转向：安全、权限、生产落地类词汇涨幅超40%-80%，而Claude、Claude Code、Codex等主流模型品牌词普遍下跌20%-35%。 整个AI智能体赛道已经彻底告别「拼技术噱头」的阶段，接下来的核心竞争，是谁能真正解决落地问题、管控风险、实实在在提升效率。 注：数据来自社区周度归档，评论数为统计时点快照。

原来我的grok老师长这样

这位博主将Harness Engineering做成了可视化的动画。 他认为，理解 AI Agent 的发展方向，关键不在模型本身，而在于学习并做好 Harness Engineering（代理runtime工程）。因为，模型只是其中一部分，当 Agent 开始读文件、调用工具、修改状态、跨多步执行时，系统质量将越来越取决于模型周围的软件层（harness）。要点如下： Harness 的职责：管理上下文选择与压缩、工具接口与权限、执行控制、持久状态、检查点、限制和执行轨迹。 长任务带来的难题：历史越积越多，不能全部重放；需要决定哪些信息留在上下文、哪些摘要/检索、哪些放到窗口外持久状态；还要支持中断恢复、避免重复劳动、控制高风险操作，并保留足够轨迹便于排查错误。 工程工作内容：通过查看执行轨迹、在代表性任务上评估、分析反复出现的失败模式，然后改进上下文策略、工具暴露方式、状态处理和运行时控制。 关键洞察：很多 Agent 的失败，并非靠换更强模型就能解决，而是要调整“模型看到什么、工具怎么暴露、状态怎么保存、失败后runtime怎么处理”。随着任务变长，Harness Engineering 才是把模型能力变成可控、可检查、可测试、可迭代执行过程的关键。

越学agent越觉得，本质就是个loop，而且人类和模型都在双向试错，最后token消耗最小，速度最快，上下文最可靠的版本终将胜出

呐，看过我帖子的都知道这种把戏了

今天学到了一个小技巧： 提前写好脚本，下次一有新发模型就让模型执行脚本打游戏，关键是要快，这样你就能制作爆款ai打游戏的视频了。

感谢Jack和小波，没想到ComfyUI操作这么简单

睡个午觉的功夫，排版、总结、设计，全搞定了

实测了用codex+canva和codex+figma制作小红书图文模板的效果。 canva优点是，快，消耗的额度小。缺点是，它不听指令，有时生成的风格和图文描述完全不同。而且有bug，它生成了一个图文模板，结果去canva网页版的项目栏里怎么也找不到，过了一段时间后又突然冒出来。非常神奇。 figma是没有上述canva这些缺点的。它非常可靠，你提的每一个需求它都会认真执行。但是figma有点慢，而且消耗的额度更多。 如果不差钱和时间，其实用figma设计更好，它更能按照设计师的要求做调整。如果想日常做一个demo，而且额度还不是很足够的情况下，就用canva吧。

Everyone talks about making LLM inference faster. A surprising amount of serving performance, however, comes from work happening around the model rather than changes to the model itself. The server can avoid recomputing old work, keep batches occupied, use KV-cache memory more efficiently, or schedule prefill and decode differently. These 6 techniques each attack a different source of waste. 1/ Prefix caching Suppose many requests begin with the same system prompt, document or few-shot examples. The KV states for that shared token prefix have already been computed once. Prefix caching lets a later compatible request reuse them instead of running the same prefix through prefill again. The saving is specifically repeated prefill work. The uncached suffix still has to be processed, and decoding still runs. 2/ Continuous batching Autoregressive requests rarely finish together. With request-level batching, shorter requests can finish while longer ones keep running. Iteration-level scheduling allows finished requests to leave and waiting requests to enter between iterations. Nothing about the model changed. The scheduler simply stops tying GPU capacity to the lifetime of one fixed group of requests. 3/ PagedAttention The KV cache grows as a sequence grows, while its final length is unknown beforehand. Large contiguous reservations therefore waste memory through over-reservation and fragmentation. PagedAttention divides KV states into blocks. A sequence's logical blocks can map to physical GPU-memory blocks that are not contiguous, so memory can be allocated as the sequence grows. This is why PagedAttention is fundamentally a KV-memory management idea, not a faster attention approximation. 4/ Chunked prefill A long prompt can produce a large prefill iteration while existing requests are waiting for their next decode step. Chunked prefill splits that prompt processing into smaller pieces. The scheduler can mix those pieces with decode work instead of letting one large prefill monopolize an iteration. There is a trade-off: smaller chunks can reduce decode stalls, but chunking can also add prefill overhead. 5/ Speculative decoding Normal autoregressive generation requires repeated target-model steps. Speculative decoding lets a cheaper draft model propose several tokens first. The target model then evaluates those draft positions together. With the classic acceptance and correction procedure, several proposed tokens can be accepted while preserving the target model's sampling distribution. The method only pays off when the target steps saved are worth more than drafting and verification. 6/ Prefill/decode disaggregation Prefill and decode have very different execution characteristics. Prefill is typically much more compute-intensive. Decode, especially at modest batch sizes, is often constrained more by memory bandwidth. Systems such as DistServe and Splitwise therefore place them on separate worker pools. Prefill workers build the KV state, that state is transferred, and decode continues on separately provisioned workers. The cost of that KV transfer is part of the trade-off. Once you see the bottleneck each technique is addressing, the names become much easier to remember. Prefix caching saves repeated computation. Continuous batching saves idle batch capacity. PagedAttention saves KV memory. Chunked prefill reduces prefill/decode interference. Speculative decoding reduces serial target-model work. Disaggregation stops two very different phases from being forced into the same resource configuration. The model can be identical in all six cases. What changes is how much unnecessary work the serving system does around it.

非科班学习ai agent的第十五天，今天继续deeply seeking dsh。 dsh是用来开发插件的，而做插件的起点就是先理解接下来要讲的profile。 profile可以理解为dsh展示给用户使用的界面。官方内置的profile有两个：一个是web，还有一个是headless。web就跟网页版的gemini、chatgpt、grok差不多，而headless有点像wsl上运行的claude code、codex，但不同在它是一次性CLI任务，没有上下文记忆。一个官方提供的profile目录模板长这样，咱们套就完事了： profiles/web/ # 或者 profiles/headless ├── package.json # 插件依赖 + dsh.profile 清单（bundles 顺序） ├── cordis.patch.yml # 你的补丁层：挂载/覆盖插件的声明 ├── cordis.yml # （生成的）合成配置 ├── pnpm-workspace.yaml └── node_modules/ 启动profile时，加载顺序如下：内置 bundle（dsh-base → dsh-web-app）→ profile 的 ~/.dsh/cordis.patch.yml → 用户级 ~/.dsh/cordis.patch.yml → --patch 覆盖层。其中: 1.dsh-base 是 DSH 的共享核心，也是 web、headless等绝大多数 Profile 的第一个加载层 2.dsh-web-app 是一个构建在 dsh-base 之上的补丁层（Patch Layer）。它的作用是为 dsh-base 的核心能力添加完整的浏览器图形界面，让用户可以通过 Web 页面与 Agent 交互。 3.dsh-base和dsh-web-app被称为Bundle，在package.json中，通过dsh.profile.bundles 字段 "bundles": [ "@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app" ] 定义了加载顺序。 4.profile和bundle之间的区别，类似于拼好的成品，和零散的积木之间的关系。 5.~/.dsh/cordis.patch.yml默认并不存在，是一个可选的用户级补丁文件，需要手动创建。 dsh允许开发者让插件实现host或client功能。可以二选一，做host半或client半，也可以全选。只要事先在package.json添加声明即可。 还有，官方声明了改dsh行为的原则：改行为，优先找钩子。意思是：**当你想要改变 DSH 的某个行为时，优先使用官方提供的扩展点（钩子）来介入，而不是直接去修改 DSH 的源代码（fork 核心），**以免官方更新时要手动合并改动，还和社区插件生态隔离。 当我们真正去开发插件的时候，我们可以参考官方提供的项目骨架模板先创建文件： dsh-speed-plugin/ ├── package.json # host 插件声明 ├── tsconfig.json ├── src/ │ ├── effort-decision.ts # 纯函数：决策逻辑（零依赖，可单测） │ └── index.ts # apply(ctx)：接入扩展点 └── tests/ └── effort-decision.spec.ts 我按照教程的实战案例，准备编写一个可实现降档提速的插件。因为我只学过python，并未学过typescript，所以这一块打算边看代码边问ai完成。由于时间有限，我无法完全搞定这个实战项目，只能先大概了解提速插件的三层架构： 纯函数层 / 插件主体层 / 测试层。 然后是测试中的三层测试： 纯函数单测 / waterfall契约测试 / agent循环验证。 明天再打算实战操作一下。