做了快两年的AI Agent项目我一直被一个看似不起眼、实际上特别磨人的问题困扰模型生成的文本总是要不就啰嗦得像个没完没了的话痨要不就生硬得像个提前写好的公告模板。你说它错吧意思都对你说它对读起来就是别扭。后来我慢慢意识到这不光是提示词写得不够好背后是一个更系统的问题——LLM在AI Agent里的文本复杂性调整能力。这个能力直接决定了Agent产出的报告、回复、中间过程是不是真的“能看、好用、像人写的”。这篇文章我不打算讲那些玄乎的理论就踏踏实实把我在几个真实项目里摸索出来的经验、踩过的坑、最终沉淀下来的方法一五一十地写出来。1. 从单轮聊天到多步Agent文本复杂度控制为什么突然变得这么难先说个反直觉的现象。很多人在单轮ChatBot里觉得模型输出还挺正常一旦把它接入Agent工作流开始让它自主调用工具、总结中间结果、生成最终报告就发现文本质量全面失控。这不是你的错觉而是问题本身变了。1.1 传统单轮对话的“提示词幻觉”害了不少人在单轮对话里你给一句prompt模型直接回答。写作风格、长度、语气这些靠一两句话通常就能约束住。比如“简要回答”“不要超过200字”模型大体能配合到位。问题在于这种控制是单向的、被动的。模型不需要主动判断什么时候该详细、什么时候该简略它只要照着指令的字面意思输出就行。这种模式给你一种错觉模型天生就“懂”文本复杂度控制。等到把同样的prompt技巧搬进Agent里效果就完全不一样了。Agent需要先理解用户原始需求拆解成多个子任务调完一两轮工具中间可能穿插思考、检索、计算最后把一堆结构化或半结构化的结果合并成自然语言答复。这个过程中每次上下文微小的变化都会让模型对“现在该输出多复杂”的判断产生漂移。1.2 Agent场景下的三层文本失控我挨个遇到过我把实际项目里遇到的现象总结成三层方便定位问题第一层目标漂移。用户最开始问的是“帮我看下这份合同里付款条款的风险”Agent中途检索完法条之后很可能脑补出一个任务开始给你讲整个合同法的背景知识。输出确实更“复杂”了但恰恰偏离了用户真正需要的简洁风险摘要。这是目标层面的复杂度失控——信息量是多了相关性反而下降了。第二层格式污染。Agent工具调用返回的JSON、检索到的片段、内部思考标记时不时会漏进最终文本里。用户看到的是“根据query匹配到3条结果……”这种半结构化、夹杂非自然语言的表达在人类读来非常“不自然”。这不是模型不会写而是Agent链路里格式切换太多边界没管住。第三层复杂度失衡。该精读的地方一句话带过该一句话说清的地方突然展开几百字。我在一个智能客服工单分类项目里就见鬼了——模型把“退款流程”解释成了五百字的论文式说明可是对真正关键的“是否已超过退款时效”这个判断反而只甩出“未超时”三个字。这三层失控叠加起来就造成我开头说的那种结果文本看着没什么大毛病但通篇都是“读起来辛苦用起来费劲”的低质量表达。2. 文本“复杂性”不是模糊感觉而是能被量化的四个具体维度要解决一个问题首先得精确描述它。“文本复杂性”这个词太虚了我在团队里经过好几轮讨论最终把它拆成了四个能检查、能改、能度量的维度。2.1 词汇层高频词、长尾词与过度书面化的信号词汇层面的复杂性可以观察三类指标词频分布是否反复使用“实现”“提升”“确保”“相关”这类万能动词词汇多样性TTR去重词数占全文总词数的比例。TTR太低说明翻来覆去就那几个词读起来单调太高则可能是在堆砌生僻词。书面化程度口语场景出现“倘若”“予以”“鉴于”技术场景反而出现“炫酷”“拉满”都说明词汇层级选错了。我处理过一个内部知识库问答Agent它生成的周报摘要里“有效提升”出现了七次每次出现的语境还都不一样。这种词频失衡就是典型的词汇层复杂性没调好。2.2 句法层平均句长和嵌套深度说了算句法层面最容易量化的指标是平均句长和从句嵌套深度。比如下面这句就是我在一个项目里真实见过的模型输出为了进一步提升用户的留存率我们参考了过往的流失用户行为数据结合最近三个版本的功能迭代记录通过聚类分析识别出了五个在卸载前表现出高度异常活跃特征的用户行为模式这些模式在经过交叉验证之后显示出了相对稳定的预测性能因此建议后续运营策略可以以此为基础进行针对性优化。这句话就是一个典型的长句失控案例。它一逗到底中间塞了至少四个从句嵌套。我拿依存句法分析工具跑了一下最深层级达到了7层人类读一遍需要前后来回扫三次才能理清意思。模型其实并不天然倾向于写长句是Agent上下文里塞满了复杂的中间结果它不自觉地把这些信息“压缩”进了一个句子里。控制句法复杂度的本质就是帮模型把信息切成适当大小的块。2.3 语义层信息密度要的是“稠但准”语义层面的复杂性最直白的说法是信息密度——每一个字、每一个词到底有没有在传递新信息最典型的信息冗余长这样不可否认的是从某种程度上来说对于用户体验这一块而言它确实存在一定的提升空间。这句话一层套一层全是修饰和缓和语真正有用的话无非是“体验有待提升”。信息密度极低。反过来信息密度过高也致命。我见过模型在生成技术文档摘要时一句话里塞四个专有名词缩写没有一句过渡或说明新读者完全看不下去。语义层的目标不是把文本变大或变小而是保证“单位长度内的有效信息量”落在目标读者的舒适区里。2.4 结构层Agent产物特有的信息组织复杂度还有一层是普通文本生成很少讨论但Agent场景必然面对的结构层。包括标题层级、列表嵌套、重点排版、Markdown标题怎么安排、JSON字段怎么组织。Agent产出的内容往往要落地到某个业务系统里结构本身就是信息。结构太浅信息关系表达不清结构太深人类读起来又累赘机器解析也容易出错。比如一个项目汇报Agent把三级、四级标题和五六层嵌套列表全用上反而让真正的核心结论淹没在层级里。结构层的复杂度控制核心是明确“这个输出是给人看还是给另一个Agent看”这直接决定嵌套深度和层级数量的上限。3. 一套立即可用的调整工具箱从提示工程到解码参数的组合打法把难题拆解清楚之后下一步就是动手调。这部分是纯干货我会按生效优先级排序。3.1 提示词侧“复杂度标尺”加“示例锚定”我的第一个发现是光告诉模型“要简洁”或“要详细”是不够的——太抽象。模型对“简洁”的理解可能和你差了十万八千里。后来我改用复杂度标尺效果立刻好了很多。原理是给模型一个可对照的尺度而不是模糊形容词请按照以下五级复杂度标准输出 1级仅给出结论或行动项不解释原因。 2级给出结论一个关键理由。 3级给出结论核心理由必要的上下文。 4级在3级基础上补充可能的风险或例外情况。 5级在4级基础上提供完整的推导过程、备选方案、数据支撑。 本次任务的输出级别2级这套方案在我们项目里落地后输出长度方差立刻降低了40%以上。关键就在于把不可测量的形容词换成了可对齐的分级指令。还有一招是示例锚定。别只给规则直接给一个“我认为理想输出长这样”的例子。模型对例子的模仿能力远强于对指令的理解能力。我给客服工单Agent写了几个范例从“过于啰嗦版本”到“理想版本”各放了一两个输出质量肉眼可见提升了一个档次。3.2 解码参数温度、Top-P和频率惩罚的真实影响很多人调解码参数时只看温度实际在文本复杂性控制里频率惩罚frequency_penalty的影响比温度更直接。我做过一组对照实验。同一批复杂法律文本摘要任务固定温度是0.3分别用频率惩罚0、0.3、0.7跑了一遍频率惩罚平均输出字数生僻词数量观察现象0630较少偏向套话大量重复“相关”“有效”0.3520中等重复减少句式明显多样0.7460较多开始出现不稳定的生僻词偶尔跑偏频率惩罚的本质是对已出现过的token施加“重复抑制”。惩罚越小模型越容易吃到“惯性路径”上重复模板套话惩罚调高它被迫绕开常用词去找新的表达路径——但惩罚太高又容易绕到生僻词或病句上。温度的作用则常规很多温度越低token分布越锐利输出越定式温度越高越发散可能带来越丰富的措辞也带来越高的跑题风险。在文本复杂性调整里把温度控制在0.2到0.7之间再配合频率惩罚比单调温度要精准得多。3.3 分支策略把“生成”拆成“起草”和“修改”两段这是我自己项目里最有用的一个进阶打法。不要让模型一步到位输出最终文本而是拆成两个阶段第一阶段让模型以“起草者”身份放飞写一版完整内容先把事实铺开不限制篇幅。第二阶段把第一版内容作为输入让模型以“专业编辑”身份按目标复杂度标尺进行改写。我习惯用类似下面的提示词你是一名严格的文字编辑。请对下面的初稿进行改写目标如下 - 信息不要删减但句式必须重构 - 禁止使用“值得注意的是”“不可否认”等填空式套话 - 每个段落只保留一个核心意思 - 句长控制在平均20字以内 - 改写后不得出现任何AI常用书面腔 初稿如下 {first_draft}效果非常显著。实验下来单阶段直出文本平均要改3轮才能让人满意两段式流程基本一轮就能定稿。核心原因是生成和修改本质上需要两种完全不同的注意力分配——生成要发散修改要收敛。让模型同时干这两件事它很容易哪头都顾不好。4. 后处理与结构化约束模型“不听话”时的兜底方案提示词和解码参数属于“提前预防”。但我得诚实地说模型总有发挥失常的时候所以我后来直接在管线里加了一道后处理。4.1 规则过滤器先干掉快捷键式的机械表达这一层很简单但很管用。我维护了一份“机械表达黑名单”里面是长期看下来模型最常用的套话值得注意的是不可否认的是综上所述从某种程度上来说综上所述首先、其次、最后这种无意义排比引导作为一个语言模型在当今……的背景下当Agent的最终文本命中这些词时不做拒绝而是用改写模块自动替换。这种做法听起来很暴力但非常有效。这些词不是不能用而是它们的出现频率几乎总伴随着低信息密度的空洞表达。4.2 长度走廊超出范围就强制触发改写我还给不同类型的输出设了“长度走廊”工单回复80到150字周报摘要200到350字技术方案评估600到900字对外公告300到500字统计输出字数一旦偏离走廊就自动进入改写流程。比如目标200字模型直出380字我先把“请缩减到200字以下”和初稿一并丢给模型再套一遍语言过滤。这里有个细节不要让模型直接“缩减”要告诉它保留什么。直接说“缩减到200字”的做法模型通常只会删掉修饰保留事实骨架结果就是信息密度反而失衡、读起来很干。更好的指令是“找出三个最核心的要说明的点用200字把它们讲清楚”。效果会完全不同。4.3 对Agent中间过程Token做“隔离”文本复杂性失控还有一个隐藏来源——Agent工具调用产生的中间Token混进了最终上下文。我后来强制做了处理工具返回结果、检索片段、内部推理标记不允许拼进最终文本上下文只允许被引用其结论。实际操作上有些Agent框架支持单独控制“可见性”如果没有那就得在组装上下文的时候手动过滤。特别是那些带JSON结构的推理链条不隔离的话模型很容易把JSON里字段名直接抄进自然语言输出导致用户看到“根据Question字段和Context字段”这种莫名其妙的话。5. 文本复杂性调整的更上游思路结构化输出与格式限制这部分是我踩过一大轮坑之后才意识到的很多“文本复杂性”问题根源上不是文本问题而是格式问题。5.1 用JSON Schema先定骨架再填充血肉Agent和普通ChatBot一个重大差异是它的输出通常还要被下游系统消费——入库、触发流程、转给其他模块。如果把所有输出都当成自由文本复杂度完全靠模型心情控制那结果必然不可控。更靠谱的思路是先定JSON Schema再让模型按Schema填内容。我举个实际项目里的例子。某内部运营分析Agent最终要输出一条建议。以前让模型直接写一段话结果千奇百怪。改成结构化后{ type: object, properties: { 结论: { type: string, maxLength: 100 }, 支持事实: { type: array, items: { type: string, maxLength: 200 } }, 风险备注: { type: string, maxLength: 150 } }, required: [结论] }让模型严格按这个结构输出再对每个字段做长度限制文本复杂性问题直接被“逼”没了——因为Schema本身就限制了结构的层级和信息的组织方式。5.2 分段生成避免一篇长文All-in-One另一个非常实用的技巧是把长文拆成多个短生成任务。例如让Agent生成一份项目复盘别让它一口气写全文。可以拆成先产出数据摘要表格再产出三个关键结论点然后基于结论点生成每一段的正文最后拼装、润色每段都是独立调用每段都配上独立的复杂性要求。这样带来的好处是模型的注意力更集中不太会前10句还正常、后10句就开始套话连篇。5.3 判断“给谁看”决定格式取向我做这个“给谁看”判断时总结了一个原则表消费方格式取向复杂度控制重点最终用户人自然语言优先少用嵌套结构句长、信息密度、语气自然度下游Agent结构化优先字段明确上下文切分避免字段混淆强监管场景审核无歧义优先少用模糊表述不省略条件、例外情况管理层快速阅读结论前置细节分层层次清晰执行项可检索这个表格很朴素但每次我对Agent输出拿不准的时候拿它一对照该往哪个方向调就很清楚了。6. 什么时候值得动用微调成本、效果和边界有些复杂度的控制光靠提示词和后处理确实到不了那个精度。尤其当你发现同样的任务换个用户说法模型就“崩”了或者你的业务里有一批高度统一的专业表达习惯这时候就想到了微调。6.1 轻量方案优先微调是最后手段我的建议始终是先试两到三周的提示词后处理组合再考虑微调。原因是微调的成本不只在训练本身它在数据管理、迭代周期、回归调优上都绑着大量人力。但有些场景提示词真的顶不上。比如一个垂直法律领域Agent需要大量输出“法言法语”风格的结论同时又要逻辑严密。提示词堆了无数轮模型输出还是“过于平实”缺少领域老手那种“结论-依据-例外-建议”的天然表达节奏。这种情况靠示例库勉强改善但边际收益越来越低最终值得做一次微调。6.2 微调数据怎么造才是关键微调最重要的不是训练参数而是训练数据的组织方式。我把微调数据的标准做法总结成这样每个样本统一包含“任务输入”、“中间状态”“理想输出”。理想输出必须经过2到3轮人工改写确保不是直接把模型原始输出拿过来标注。每个样本标注其“复杂度级别”并确保训练集里级别分布覆盖你实际业务场景。大量样本保持同一知识领域避免混入不相关任务的改文导致模型学偏。我自己参与过的一个项目用约800条精选数据做了轻量微调效果确实比提示词方案稳定很多。但我要强调一句它写不出超纲内容如果你的业务在快速变化微调模型的更新会拖你后腿。很多团队做不了这个决策就是低估了后续迭代的负担。6.3 一条比较合理的决策路径我现在一般按这个路径做决策先明确复杂度失控是否频繁出现、是否严重影响业务——如果只是偶发后处理够了。统计需要“特殊表达风格”的任务占比占比低于30%倾向别做微调。如果任务风格要求统一且稳定才好上微调。微调上线后每三个月评估一次是否需要增量更新否则模型表达能力会悄悄退化。7. 验证与评测怎么知道自己到底调对没有调整文本复杂度最忌讳的就是“凭感觉”。我吃过这个亏——自己觉得输出变简洁了给用户看一眼人家还是觉得绕。7.1 用可计算的指标约束“文本复杂度”的四个维度基于前文四个维度我实际采用的评测指标是维度指标理想区间参考词汇TTR类符形符比0.45~0.65句法平均句长15~25字句法从句嵌套深度不超过4层语义有效信息密度评分人工评估为主结构标题层级数不超过3层结构列表嵌套层级不超过2层这些指标都是跑一个Python脚本就能算出来的核心代码长这样def compute_complexity_metrics(text): sentences re.split(r[。], text) sentences [s for s in sentences if s.strip()] avg_len sum(len(s) for s in sentences) / len(sentences) words re.findall(r\w, text) ttr len(set(words)) / len(words) if words else 0 return { avg_sentence_len: round(avg_len, 1), ttr: round(ttr, 3), }7.2 一套小但高效的评测集比大规模评测更解决实际问题我不建议一上来就搞几百条数据的评测集成本太高迭代也慢。我的做法是建一个50条以内的高质量小评测集专门找那种“容易让Agent失控”的输入长上下文、多工具调用历史用户输入本身信息密度就很高需要高度融合多来源知识目标输出需要明确的复杂度阶梯用这个小评测集跑一遍人工看输出是否符合复杂性预期再把结果对齐到上表指标。这套流程跑顺之后每次调参都能得到可对比的量化反馈效率高很多。7.3 我踩过的一个评估误区之前我们的团队只看“长度”觉得Agent输出越短越好结果一段时间的打磨后文本确实短了但关键信息也被压没了。用户在测试时普遍反馈“说了跟没说一样”。这是复杂度控制的另一个极端——过度压缩。好的复杂度控制是在“信息完整性”和“表达精炼度”之间找平衡点而不是一味往短里写。后来我把评测指标里新增了“关键信息是否完整”项由测试人员逐条打勾才把这个偏差扳回来。8. 实战中容易踩的坑清单最后这部分我把这几年踩过的坑做一个收拢每条都是真金白银换来的。8.1 不区分任务类型就统一套“简洁指令”最大的坑。不是所有Agent输出都要简洁。写故障复盘要详尽写待办摘录要精炼对外周报要结构化。一个统一的“请回答得简洁一些”挂在所有提示词上模型处理不同任务时就会来回摇摆。我的做法是每个任务类型单独维护一张“复杂度配置”数据存成一份YAML或JSON写清楚输出级别、目标字数、措辞风格。让模型根据任务类型自动匹配配置。8.2 把结构化误当成文本复杂性有种很常见的情况Agent给出的内容结构分明、框架完整但每个段落都空洞浮泛。这其实是把“表面复杂度”和“深层质量”搞混了。结构只是骨架每个节点里的信息密度才是血肉。评审Agent文本质量的时候先看内容再谈格式别被漂亮的标题层级骗了。8.3 只调提示词不改解码参数和温度提示词能解决的复杂度问题其实非常有限。尤其当模型频繁输出套话、重复句式时你再多写“不要重复”都会被打折扣。这时候把频率惩罚上调一点立刻有变化。文本质量调优是一门组合手艺提示词、采样参数、后处理必须一起动。8.4 忽略Agent状态的上下文污染Agent是多轮任务每轮产生的中间文本都会进入下一轮上下文。这些中间状态如果带着十足的“技术味”“工具味”最终生成必然会向那个方向偏移。前面对中间状态做隔离这里再强调一次隔离好中间状态比调整任何参数都重要。8.5 没有评测就跑上线然后在生产里反复补救文本复杂度控制的迭代属于典型的“没有评测就永远在救火”的工作。因为有了评测调到第五版的时候你才敢确定第五版比第三版真的更好。没有评测的话每一次改动都像是情书寄给了一个不确定的人方向全凭运气。我个人后来养成一个习惯任何改动上线前先跑一遍小评测集把四个维度的指标全部跑出来让数据说话。人眼当然重要但靠数据才能迭代。文本复杂性调整这件事本质上是把一个非常人文化的“语感”拆解成了可以度量、可以控制、可以迭代的工程问题。它没有一劳永逸的答案只有不断逼近的优化循环。做了这么多项目我最深的一个感受是一个Agent输出文本的质量几乎就是它整个系统工程质量的一面镜子。文本控制得好往往意味着你的任务拆解清晰、状态管理干净、评测机制完备文本控制得一团糟背后多半也藏着架构和流程上更深的问题。如果你现在正被Agent输出“不像人话”困扰我建议从今天开始做两件事一是把复杂度拆成可量化的维度二是建一个哪怕只有几十条的小评测集。有了这两样剩下的就只是不断微调的时间问题了。