为什么将 LLM 输出人性化对智能体工作流是适得其反的

以人为中心的输出风格会压缩智能体的工作并丢失信息

以人为导向的输出格式，如 Simplified Technical English (STE) 或短句提示词，会迫使模型将其内部推理压缩成低带宽的表示形式。

• 压缩是有损的：即使文本读起来仍然通顺，细节也会丢失。
• 智能体需要最高信息密度的表示形式来解决任务、保留抽象概念并避免破坏现有功能。
• 将风格约束作为核心指令集的一部分，会将展示与问题解决混为一谈，这与存储和显示作为独立层的传统系统不同。

"如果让你告诉一个智能体使用短句、避免术语、永远不要让你感到不知所措，并且只包含最重要的细节，你就是在要求它不断地将其输出压缩成低带宽格式。这种压缩是有损的。" – kuberwastaken, Humanising LLM Outputs is Dumb

原始智能体输出对于正确性和调试至关重要

当智能体与子智能体通信时，每一层都应该交换精确的、机器可读的数据：

5/6 PASS
FAIL: test_cache_invalidation
CAUSE: stale key survives restart
REPRO: tests/cache_test.py:184

一个像 "大多数测试通过了，尽管有一个值得关注的问题" 这样的人类友好型摘要，会隐藏了自动化修复所需的精确失败信息。

• 详细的日志会暴露冲突的证据、未解决的分支、堆栈跟踪和不确定的假设。
• 人类语言倾向于平滑这些信号，从而使检测幻觉或细微的错误变得更加困难。

现有系统设计模式在边界处保持保真度

• Databases 存储原始行；仪表板为用户进行格式化。
• Compilers 保留一个不用于人类消费的中间表示 (IR)。
• APIs 交换结构化数据，而不是叙述性摘要。

LLM 工具正在越来越多地通过在推理阶段强制进行人类可读的格式化，从而逆转这一模式。

可访问性与个性化属于最终渲染阶段

作者澄清，该论点并不是反对让输出变得可访问：

"如果你想要三行式的回答或 Simplified Technical English，没问题！我只是认为最好在最后一步做这件事。"

建议是保持智能体的内部状态、模式 (schemas)、差异 (diffs)、置信度分数和出处 (provenance) 不变，然后仅在最后一次为人类消费而进行转换。

社区对权衡的看法

• Xcelerate 指出，在长 LLM 输出之后，他们会提示进行第二次处理以 "decompress any LLM-speak"（解压缩任何 LLM 术语）供个人使用，同时为未来的智能体保留原始输出。
• 7402 分享了一个抑制了友好度与第一人称语言的提示词，旨在获得简洁、事实性的回答。
• Animats 警告说，强制风格可能会引入幻觉，而不仅仅是丢失信息。
• firefoxd 观察到，像机器人命令一样的搜索查询曾经可以产生更好的结果，但 AI 生成的概览已经削弱了这种能力。
• pholden 指出，Claude 的输出风格设置仅影响主对话；子智能体保留它们自己的系统提示词，因此风格泄漏是有限的。
• boredumb 认为，前沿模型应该优先考虑机器层面的精度，让 UI 开发人员来构建他们需要的人类友好型层。
• TheCapeGreek 和 TheCapeGreek (重复) 强调，许多用户实际上想要这种有损压缩，以避免在代码审查中出现冗长余谈。
• wren6991 反驳驳，LLMs 已经在内部进行语码转换 (例如，chain-of-thought 与最终输出)，因此为人类提供更简单的方言并不本质上是有害的。
• virajk_31 和 scotty79 建议使用专门的联络智能体 (liaison agent) 在机器最优输出与用户友好型渲染之间进行翻译。

实践建议：将 "thinking"（思考）和 "talking"（说话）阶段分离

1. 保持核心智能体输出为原始格式 – 保留完整的测试日志、错误跟踪、置信度指标和结构化 diffs。

2. 定义一个后处理步骤 – 在智能体完成任务后，调用一个格式化程序或第二个 LLM，将原始数据转换为所需的格式（例如，STE, 简洁的列表点)。

3. 通过 APIs 暴露原始数据 – 允许下游工具或人类审查员在需要时请求未经过滤的输出。

4. 将风格视为渲染器，而不是指令 – 类似于数据库查询返回行，而 UI 组件进行格式化。

通过坚持这种分离，开发者可以保留可靠自动化所需的保真度，同时仍能为最终用户提供可访问的、个性化的摘要。

---

该讨论反映了 AI 工具链的广泛转向：从单体式、以人为中心的提示词，转向分层架构，其中机器之间通过精确、机器友好的语言进行通信，并仅在最后一层将其翻译成人类可读的形式。