2026 年 9 月,一个名为 I-have-ADHD 的开源项目登上了 Hacker News 榜首,获得了 541 个点赞和 72 条评论。这个项目的核心功能出人意料地简单:它是一个 Coding Agent 的「技能包」(skill),用来阻止 Agent 把答案埋在冗长文本里。这个名字带有些戏谑色彩,但它解决的是一个真实且高频的工程问题——主流 Coding Agent(尤其是 Claude 系列)的默认输出风格倾向于铺陈背景、列举细节、最后才给出结论,这种「论文式」输出对任何需要快速决策的用户都不友好,更不必说有注意力挑战的用户。这个项目的爆火反映了一个正在浮现的工程新领域:Agent 输出工程——不是优化模型本身,而是优化模型与人类之间的「最后一公里」信息传递。同一时期,一个分支项目把这个洞察推向了更严格的工程框架,提出用「决策预算」(decision budget)作为输出长度的唯一标尺,让 Agent 输出从「修辞合理」升级为「可决策」。
一、问题的本质:Agent 输出的「论文式」失配
Coding Agent 的输出失配不是一个边缘问题,而是所有使用 Agent 的开发者每天都会遇到的痛点。在 Hacker News 的讨论里,开发者们用各种方式描述同一个现象——有的说 Agent 「会给出十页论文最后总结为『没问题,一切正常』」;有的说「重要细节埋在文本中间,需要逐行扫描才能找到」;有的抱怨「最后几行标注『重要』的内容,其实是之前对话里早就提过的旧信息」。这些反馈的共同指向是:Agent 的输出长度与「用户需要做的决策数量」严重脱节。Agent 工作了 30 分钟但一切顺利,会输出 800 字总结;Agent 试了 3 个分支方案发现都不行,可能只输出 200 字简短说明。决策密集度与输出长度倒挂,这种失配让用户必须完整阅读所有输出才能确认「是否需要采取行动」,而不是通过扫读关键段落快速判断。
这种失配的根源是 Agent 训练数据里沉淀的「写作偏好」。主流大语言模型在预训练阶段吸收了大量学术论文、技术博客、教程文档、客服话术等文本,这些文本的共同写作习惯是「先铺垫背景,再层层论证,最后给出结论」。这种风格在人类读者的传统语境里是合理的,因为读者预期作者会铺垫完整。但在 Agent 与开发者协作的语境里,这种风格变成了负担——开发者需要的不是「理解 Agent 做了什么」,而是「知道下一步要做什么」。这两者的信息密度要求完全不同。
让问题更复杂的是,这种输出失配并不是 Agent「故意」造成的,而是它的训练语料塑造的默认风格。即使在系统提示词里明确要求「先给结论」,Agent 也常常在多轮对话后逐渐回归冗长风格,因为每多一轮对话,新加入的上下文会稀释系统提示词的权重。这种「提示词衰减」是 Agent 输出工程的另一个核心难题——一次性注入的指令难以稳定维持,需要在工程层面持续加固。
二、I-have-ADHD 的工程解法
I-have-ADHD 项目把解决方案抽象成一个可被 Coding Agent 加载的「技能包」。技能包里包含一个 140 行的核心提示词(占整个仓库 8.7k 行代码的不到 2%,其余主要是评测脚本和社区贡献),提示词的核心指令是「把答案放在最前面」—— 无论 Agent 内部执行了多少步骤、查阅了多少文件、运行了多少测试,最终输出必须以「结论/决策/下一步」开篇,然后才是必要的支撑信息。这种「先结论后论证」的结构与传统学术写作完全相反,但与开发者快速决策的信息需求完全匹配。
项目作者在设计时考虑了几个关键的工程细节。第一,技能包区分了「结论先行」与「简短输出」的差异:很多用户既有的提示词只要求「简短」,但「简短」不等于「结论先行」——一个简短的寒暄、问候、铺垫都是简短,但都不是决策所需的信息。技能包明确要求输出的第一句必须是可以直接行动的结论,而不是「让我先解释一下」「以下是详细分析」这类过渡句。第二,技能包要求输出必须结构化——使用标题、列表、加粗等格式让关键信息可视化可扫描,而不是用大段连续文字让用户必须逐行阅读。第三,技能包给出了可操作的判断标准——「如果一段文字读完后用户不知道下一步该做什么,这段文字就应该被删掉或重写」。
项目在 Hacker News 上爆火后,开发者社区围绕「为什么这个功能不能直接放进 AGENTS.md 或 CLAUDE.md」展开了热烈讨论。社区共识是:技能包的形式优于全局配置,因为技能包是按需调用而非全时生效。当 Agent 输出已经符合「结论先行」的要求时,不需要再施加约束;当 Agent 输出开始偏离时,用户可以主动触发技能包进行修正。这种「按需触发」的机制比「全时约束」更灵活,也更不容易让 Agent 因为过度约束而失去表达力。
三、决策预算:更严格的工程框架
I-have-ADHD 提出了「结论先行」的工程范式,但它的核心指令仍然是定性的——「结论应该在前面」,但「结论」到底多长才算合适,「前面」前面需要多少铺垫,这些边界并不清晰。一个后续的开源分支项目把这个定性范式升级为定量的工程框架,提出了「决策预算」这个核心概念。
决策预算的核心断言是:输出长度应当与读者需要做的决策数量成正比,与 Agent 实际付出的工作量无关。具体而言,Agent 工作了 30 分钟但一切顺利,对应一行「一切按预期进行,无需操作」的输出;Agent 工作了 30 秒但发现了三个分支需要决策,对应三条编号列表,每条说明一个分支及其推荐路径。读者拿到输出后,需要做的决策数量决定了输出的必要长度——如果读者看完输出后没有任何决策要做,那输出应该尽可能短;如果读者看完输出后需要做三个选择,那输出就应该明确列出这三个选择并给出推荐。
这个框架的工程价值在于它把 Agent 输出的「合理性判断」从「修辞学问题」转化为「数学问题」。传统上,判断一段 Agent 输出是否过长,需要人类审阅者凭直觉判断;在决策预算框架下,只需要数输出的「可决策点」数量。如果输出里只有 1 个可决策点但有 500 字文字,那就有 499 字是冗余;如果输出里有 5 个可决策点但只有 50 字,那就是决策点模糊不清。这种「可量化」的特性让输出工程可以纳入 CI 流程——每次 Agent 输出后,自动统计可决策点数量与文字长度,作为一项质量门控。
决策预算框架还解决了一个 Agent 输出工程的经典难题:为什么 Agent 工作很多但用户读起来还是「不知道下一步」。答案是 Agent 把工作过程本身当作了输出内容,而不是把工作结论当作输出内容。一个跑了 100 次失败的 Agent,如果只输出「尝试了 100 种方案都失败」,就符合决策预算的要求;一个跑了 3 次失败的 Agent,如果输出 100 行的失败细节复盘,就不符合决策预算。决策预算关注的是「读者下一步做什么」,不是「Agent 下一步做什么」。
四、Agent 输出工程的组织级落地
从个人开发者工具到企业 Agent 部署,Agent 输出工程需要从「用户自己安装技能包」升级为「组织级输出规范」。第一步是建立 Agent 输出的「决策点清单」模板——每个业务场景(代码审查、运维事件、数据报告、客服应答)都有固定的决策点类型,Agent 输出必须按模板填充决策点,不能添加模板之外的冗余内容。第二步是建立 Agent 输出的「长度门控」——根据决策点数量设置输出字数上限,超出上限的输出被自动拒绝并要求 Agent 重写。第三步是建立 Agent 输出的「可读性检查」——自动检测「让我先」「以下是详细」「总而言之」这类过渡句,出现就触发重写提示。
组织级输出工程的另一项重要工作是建立「输出风格共享库」。不同业务场景可能需要不同的输出风格(技术团队偏好结论先行,客服团队可能需要先安抚情绪),但同一种风格下的具体规则应该跨团队共享。当一个团队在 I-have-ADHD 基础上定制了适合自身场景的输出规则,其他团队应该能直接复用而非重新设计。这种「共享风格库」的机制让组织级的输出工程可以快速规模化,而不是每个团队都从头摸索。
五、输出工程的下一站
Agent 输出工程正在从「修辞风格优化」走向「决策结构标准化」。下一代 Agent 输出工程的演进方向会聚焦在几个具体问题上:决策点自动识别算法的成熟——让 Agent 能自动评估自己输出的「可决策点」数量;输出风格的形式化描述——让风格规则可以被版本控制、可以被 diff、可以被 CI 检查;跨模型的输出风格迁移——同一套风格规则如何适配 Claude、GPT、Gemini、GLM 等不同模型的默认偏好;组织级风格治理——多个业务线的输出风格如何统一而不僵化、保持个性而不混乱。这些问题的解决会让 Agent 输出从「凭感觉调」走向「按规范管」。
Agent 输出工程的本质,不是把 Agent 改造成「短小精悍」的工具,而是让 Agent 与人类之间的信息传递更高效。在一个 Agent 协作密度越来越高的组织里,人类阅读 Agent 输出的时间占总工作时间的比例会持续上升——这个时间如果被冗长输出浪费,会直接抵消 Agent 带来的效率收益。决策预算与结论先行的工程实践,正是为了让 Agent 与人类的协作真正实现「链路稳定、效率可期」。模型可以换,信息传递的链路结构才是 Agent 时代企业竞争力的真正护城河。
