什么是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 位参与者 阅读完整话题
GAI is a flexible Go library for building agent-style applications on top of LLMs Comments URL: https://news.ycombinator.com/item?id=47816285 Points: 1 # Comments: 0
1:结构化agents/claude 初始提示词. 只应该放置你是谁你在什么环境,本机有什么内容,现在的项目介绍一句话. 2:mcp标准化简略化. 可以配置disable 把不需要的mcp 工具给关闭. 3:skill搭配mcp工具特化如grok/context7/adb/chrome/supabase等 4:重点model基本化 配置示范 codex config.toml （点击了解更多详细信息） claude CLAUDE.md （点击了解更多详细信息） 项目说明使用 github.com GitHub - TokenRollAI/llmdoc: TokenRoll LLMDoc for Coding Agent TokenRoll LLMDoc for Coding Agent 记忆管理使用 github.com GitHub - gaoziman/claude-context-manager: claude-context-manager for claude code claude-context-manager for claude code model setting 使用 high 代替xhigh. todoplan 任务纲要使用 chatgpt 网页的pro对话完成 pro 反代公益站点 一次对话完成一件事情. 避免长上下文. 第一是我打出来的高缓存+高token 对话切费率低. 如果你们看懂了 就知道我说的是什么. llm最爱 代码行数低于1000/1个文件 组织结构化的文件目录. 清晰的顶层目录 每个大目录都应该有claude/agents文档. 从0~1~95%号池自建 自建号池状态页1Etoken=67刀 留下小爱心 冲击lv 3 1 个帖子 - 1 位参与者 阅读完整话题
最近想给大家更新一个ai agent实战主题经验分享，大家有什么想听的 给L站佬友 分享一波有效干货 你留言即可 我后面根据大家的问题 整理 希望多一点意见和反馈，做一个有意义的文档共建分享 好久没更新了 这次想听听大家需要的内容 我做有效输出，各位佬友，还记得我叭 如果方便大家可以支持认可呀 4 个帖子 - 4 位参与者 阅读完整话题
使用hermes agent 通过MCP的方法将二者连接。 原理大概是这样 Notion ↔ [Notion 官方 MCP] ↔ Hermes Agent ↔ [FNS MCP / SSE] ↔ Obsidian ↑ ↑ hermes与FNS自部署在 VPS 都使用了什么 1.hermes agent 无需多言，类似于小龙虾openclaw这种 2.notion mcp 官方的，使用OA认证挂载后 Agent 能读 / 写 / 创建 / 搜索 Notion 页面 为什么不用 api的形式？ 因为闲鱼上卖的都是那种商业试用版，hermes 本身内置了 Notion API 适配，但因为访客账号无法在 workspace 里创建 internal integration、拿不到 integration token，所以只能走官方 MCP 的 OAuth 路径。 3. Fast Note Sync (FNS)：Obsidian 插件，把本地 Vault 同步到服务器，同时暂开 SSE 协议的 MCP 服务，Agent 走这个接口读写 Vault，这个插件是L站一位佬友制作的，十分的好用。 为什么要这样做 主要还是看重他notion的AI功能。现在的notion的ai可以去闲鱼，一个月才5块钱，可以基本上无限使用opus4.7这种模型，而且对笔记的优化相当好，这个是obsidian比不了的，但是notion这个始终是云端，而且我觉得分类做的不太好，慢慢就会变成垃圾场那种。 我看过不少人同时用notion和obsidian一起用，但每次都得手动整理，**手动搬的本质是「哪天懒了，整个系统就废了」**现在已经出现了这种例如小龙虾与hermes，利用一下。 使用hermes连接笔记软件有一个好处，你根本不用打开笔记软件，与hermes聊天，聊到一个东西，直接和他说记录到笔记中，他就会帮你整理记录。或者说你在notion中记录，在obsidian中，他都可以帮你找出来，而不用打开软件去操作。 我的notion与obsidian设置 noiton 🗂️ Hermes 知识流转中心 ├─ 📥 待归档 ← 我把要归档的东西什在这里 ├─ ✅ 已归档 ← Hermes 搬完后自动移过来 ├─ 📋 Hermes 操作日志 ← Hermes 每次干活都写一行 └─ 📖 Hermes 使用说明 ← 写给 Hermes 看的手册（关键！） obsidian Vault/ ├─ 00-Inbox/ ← Hermes 搬来的全进这里 ├─ 10-信息/ ├─ 20-配置/ └─ 30-数学/ ← 这些是我手动分类的永久位置 三条铁律 绝不做双向同步，单向： Notion → Obsidian 。搬到 Obsidian 后相当于快照，想改就在 Obsidian 里新写一份，不改已归档的。 Agent 不碰正文，ermes 只做三件事： 读取 · 搬运，加一下标签或者双链。 操作日志必须有。 踩过的坑 1.假如你是在像我一样在VPS中部署的hermes，notion的mcp OA跳转主要注意 VPS 是 headless 环境，Notion MCP 的 OAuth 回调地址默认是 http://127.0.0.1 : ，本地浏览器访问不到服务器的 loopback。解决办法是用 SSH 本地端口转发，然后在本地浏览器点授权链接，回调会落到本地端口再转回服务器完成认证。 2.hermes暂不支持SSE的mcp配置，需要补充上为 Hermes 补上 SSE MCP 支持。 1 个帖子 - 1 位参与者 阅读完整话题
本人在读大二，大专计算机，专业学习Python java vue，本人对ai agent感兴趣,给Astrbot PR过，写过很多agent插件，有自己的Blog网站，熟练使用git docker ，有自己的公益站，求助佬友们这样好找实习吗？ GitHub tooplick - Overview tooplick has 25 repositories available. Follow their code on GitHub. 6 个帖子 - 6 位参与者 阅读完整话题
佬友们有个困惑求解，自部署Qwen3.5 27B,做一套偏知识类的Agent 现在的情况就是如果走Native Reasoning输出，会暴露系统约束、工具Key啥的，模型跑去复述系统提示词，如果不开而是通过提示词约束模型输出类思维链，又感觉不是很稳定。 就是感觉模型的思维过程还是挺有用的对知识类场景还挺有启发的，但是又不希望暴露系统提示词，咋解决呢 2 个帖子 - 2 位参与者 阅读完整话题
放到 AGENT.md， 终于好多了 。 你必须使用自然道地的平实的中文进行表达。切勿使用职场黑话与商业包装词汇。切勿使用排比句。 - 禁用词汇清单 你必须将以下词汇加入黑名单。黑名单包含: 赋能、抓手、闭环、沉淀、打通、对齐、拉齐、赛道、下沉、颗粒度、粒度、底层逻辑、顶层设计、心智、痛点、拆解、复盘、矩阵、倒逼、生态、体感、很硬。 - 豁免条件说明 上述词汇仅在上下文中，需要表达物理学概念或字面本意时允许使用。例如描述道路工程时可以使用下沉。例如描述赛车运动时可以使用赛道。 - 强制替换规则 生成内容前必须进行词汇审查。你需要将商业黑话替换为常规动词或道地的名词。例如：两方沟通不可写作拉齐。提供技术支持不可写作赋能。详细程度不可写作颗粒度。 7 个帖子 - 5 位参与者 阅读完整话题
首先本人是国内 985 在读研究生，不是软文，不是软文。 辅助完成一个课程的作业，只需要手机上 发送一张不是很清晰的截图，就可以 起十几个 agent 帮你干活，干完手机 app 发消息给你通知你干完了 7 个帖子 - 3 位参与者 阅读完整话题
由于对长期任务的各层级 AGENTS.md 有优化需求，我前期用codex做了一次调研。根据调研结果建立了这个skill的框架，然后用较完整的技能优化和评测的工作流，做了技能测试和改进，包括脚本调用codex-cli模拟真实仓库环境中，用skill和不用skill的测试。 目前技能已经能初步使用。大家如果在使用中遇到问题也可以自行优化一下，可以在帖子里分享给大家。 完全可以使用一下这个技能，让ai从完整记忆（比如说codex的memory全文，而不是rg搜索一部分记忆）中判断那些规则需要沉淀到全局AGETNS.md里，试试效果。 技能如下 agents-md-improver.zip (86.7 KB) 更完整的介绍留给codex帮我总结 1 个帖子 - 1 位参与者 阅读完整话题
The Cloudflare Blog – 17 Apr 26 Agents that remember: introducing Agent Memory Cloudflare Agent Memory is a managed service that gives AI agents persistent memory, allowing them to recall what matters, forget what doesn't, and get smarter over time. [!quote]+ 今天，我们宣布推出Agent Memory的私有测试版，这是一项托管服务，可以从代理对话中提取信息，并在需要时提供这些信息，而不会填满上下文窗口。 它赋予人工智能代理持久记忆，使其能够记住重要信息，遗忘不重要信息，并随着时间的推移变得更加智能。 1 个帖子 - 1 位参与者 阅读完整话题
{ “status”: “error”, “error”: “streamTo is only supported for runtime=acp; got runtime=subagent” } 这龙虾知道报错还一直带 streamTo 求助一下 佬 到底应该怎么分发子进程啊 1 个帖子 - 1 位参与者 阅读完整话题
我之前尝试过 spec 驱动开发，但是要写一份长长的 spec 再给 AI 开发实在劝退我。别说自己写 spec，就是 AI 帮我写完，让我 review 我也没耐心看完。于是我发明了 TODO 驱动开发。 什么是 TODO 驱动开发 简单来说，就是将需求拆解后，在项目代码中需要修改处加上 TODO 注释，再让 Coding Agent 使用 git 读 diff，获取所有新增 TODO，再逐一编写代码。 TODO 驱动开发有什么优点 第一，也是最明显的优点，TODO 驱动开发是从源码出发，让你自己找到需要修改的点，可以是一个待完成的函数，一个需要新增的类，甚至是一个模块，加上对应的 TODO 信息，再转交给 agent 进行实现。你的工作流基本还是在 代码编辑器/IDE 中，不需要你改变现有工作流。 第二，Coding Agent 在读取 diff 信息时能顺便看到代码上下文，不需要你费劲说明应该改哪个模块。 第三，由于已经明确具体修改点以及每个点的修改逻辑，对于没那么强的模型也能有相对更好的执行效果。 第四，由于已经明确具体修改点以及每个点的修改逻辑，Coding Agent 的改动更可控，Review 起来也更容易 2 个帖子 - 2 位参与者 阅读完整话题
虽然目前有一个 zenobi-us/pi-dcp ，但是已经两个月没更新了。 之前用opencode的时候感觉 Opencode-DCP/opencode-dynamic-context-pruning 很好用，可以不声不响地把context 保持在一个很低的水平。 换到pi-agent后，context动不动就飙升到40-50%。试了一下 mksglu/context-mode 和 MasuRii/pi-rtk-optimizer ，效果都不明显。用pi-agent的佬们，有没有什么好的管理办法？ 1 个帖子 - 1 位参与者 阅读完整话题
从 Any牌路由器 SubAgent 和 Haiku 模型无法正常调用的解决办法 继续讨论： 叼毛 就在今天 114 版本将npm包中的cli.js 之于node 的兼容运行部分 制品 全面更换成了 bun版 且学codex 把每个平台的制品都拆成了单独的分包 原本的 cli.js 的包现在改为了 包装脚本 cli-wrapper.cjs 用于拉取对应平台的 bun版二进制 其安装脚本 可以看到 基本是毁了 解包还出来 cli.js 也可以 但其目前的动作其实表明了 npm包的真废弃 不过也没有一步到位 因为最开始就是用bun构建但是兼容了node的 所以114目前解出来的 仍然可以 node来跑 只不过不确定后续动作 （等会整个仓库来分发新node版） 如果某日开始 cch的机制更进一步的 完全强硬实施（禁用的的环境变量移除掉） 或者 源码中直接将兼容node这部份包裹代码给移除 那时就是真正的废弃之时了 你让我强行用npm包我也不敢用了 （怕封号） 附一个乐子 有时候谣言是怎么传播的呢就很好奇 我们并未清楚那天穿山甲到底说了啥 25 个帖子 - 23 位参与者 阅读完整话题
上回书说到 Kimi 699 的套餐用完了，说一下感受吧 你和我想的一样，我在学校一直想做个 Deep Research Agent，这个模型真的很合适，但是没来得及实现想法就过期了 如题，站内搜了几个效果都不是很理想，要不就是接的搜索引擎太垃圾（没用google），要不就是根本不是像对话一样的 Agent 个人很喜欢 dr.miromind.ai，但是近期收费了，实在不愿意蹬他们，他们也得活着 求推荐 10 个帖子 - 4 位参与者 阅读完整话题
子agent一直无法调用 5 个帖子 - 3 位参与者 阅读完整话题
先说下我的环境：win11 安装hermes agent（原生安装非WSL）。配置好飞书后，聊天不到5次，直接挂了 。而且重启也启动不了！！ PS C:\Users\User> hermes gateway run ┌─────────────────────────────────────────────────────────┐ │ Hermes Gateway Starting… │ ├─────────────────────────────────────────────────────────┤ │ Messaging platforms + cron scheduler │ │ Press Ctrl+C to stop │ └─────────────────────────────────────────────────────────┘ Traceback (most recent call last): File “”, line 198, in _run_module_as_main File “”, line 88, in run_code File "C:\Users\User\AppData\Local\hermes\hermes-agent\venv\Scripts\hermes.exe_ main .py", line 10, in File “C:\Users\User\AppData\Local\hermes\hermes-agent\hermes_cli\main.py”, line 6546, in main args.func(args) File “C:\Users\User\AppData\Local\hermes\hermes-agent\hermes_cli\main.py”, line 789, in cmd_gateway gateway_command(args) File “C:\Users\User\AppData\Local\hermes\hermes-agent\hermes_cli\gateway.py”, line 2911, in gateway_command run_gateway(verbose, quiet=quiet, replace=replace) File “C:\Users\User\AppData\Local\hermes\hermes-agent\hermes_cli\gateway.py”, line 1631, in run_gateway success = asyncio.run(start_gateway(replace=replace, verbosity=verbosity)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “C:\Users\User\AppData\Local\Programs\Python\Python311\Lib\asyncio\runners.py”, line 190, in run return runner.run(main) ^^^^^^^^^^^^^^^^ File “C:\Users\User\AppData\Local\Programs\Python\Python311\Lib\asyncio\runners.py”, line 118, in run return self._loop.run_until_complete(task) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “C:\Users\User\AppData\Local\Programs\Python\Python311\Lib\asyncio\base_events.py”, line 654, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ File “C:\Users\User\AppData\Local\hermes\hermes-agent\gateway\run.py”, line 9876, in start_gateway existing_pid = get_running_pid() ^^^^^^^^^^^^^^^^^ File “C:\Users\User\AppData\Local\hermes\hermes-agent\gateway\status.py”, line 434, in get_running_pid os.kill(pid, 0) # signal 0 = existence check, no actual signal sent ^^^^^^^^^^^^^^^ OSError: [WinError 11] An attempt was made to load a program with an incorrect format 7 个帖子 - 5 位参与者 阅读完整话题
配置了好几次都不行，总是提示这样的错误 API call failed (attempt 1/3): BadRequestError [HTTP 400] Provider: kimi-coding Model: kimi-k2.5 Endpoint: https://api.moonshot.ai/v1 Error: HTTP 400: Error code: 400 Non-retryable error (HTTP 400) — trying fallback… Non-retryable error (HTTP 400): HTTP 400: Error code: 400 Non-retryable client error (HTTP 400). Aborting. Provider: kimi-coding Model: kimi-k2.5 Endpoint: https://api.moonshot.ai/v1 This type of error won’t be fixed by retrying. 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://agenticdev.blog/ Comments URL: https://news.ycombinator.com/item?id=47811916 Points: 2 # Comments: 0