前几年，与语言模型相处的日常动作很轻：打开对话框，改几个字的提示，期待更漂亮的一段回答。提示工程像调音——敏感、即时，也容易把失败归咎于「还不够会问」。近一段公开讨论里，另一种说法抬头：人们开始谈「挽具」（harness）——不是再拧一句咒语，而是在模型周围装上工具、校验、记忆与审批闸门，让它在多步任务里少摔跤。
热议页上的概括大致如此：开发者从反复打磨提示，转向「挽具工程」——用循环、工具调用、状态与安全门包住模型；也有人分享在较强模型外再搭一层：路由给更轻的模型处理琐事、夜间自动复查并修补、发代码前强制人工批准。另有讨论把同一思路说成「缰绳与马鞍」：没有挽具，重复与核验全压在人身上；有了它，智能体才更像可交班的工人，而非一次灵光的表演。
可靠往往来自结构，而不是来自一次惊艳的回答。
把隐喻说白一点：模型像力气很大的马；挽具是缰绳、鞍具与护腿——规定它能跑向哪里、何时必须停下、摔了如何自己爬起来再被看见。公开实践里常见的零件并不神秘：可调用的工具（读文件、跑测试、查文档）、可持久的记忆或工单状态、失败后的重试与自检、以及「危险动作先过闸」的人工审批。有人报告任务耗时下降，有人强调同一模型换一层挽具后成功率明显不同——数字来自各方自述与摘要，本稿不作未核验的跑分断言。
争论也在。有声音主张：与其堆自定义控制层，不如吃透某家「自带挽具」的运行时，再把行为写进清楚的指令；也有人坚持生产环境必须自建重试、审计与策略。两边其实共享同一判断：智能体的瓶颈，越来越不像「会不会聊天」，而像「周围的制度是否扛得住」。单智能体加技能、还是多智能体分工，都可以被收进这幅图——先量评、再加层，比先加层再后悔更省事。
【推论】若可靠主要来自结构，我们该改的就不是对模型的崇拜或恐惧，而是对流程的诚实：哪些步骤允许自动，哪些必须签字；哪些错误可以夜间自愈，哪些必须吵醒人。挽具不会取消判断，它只是把判断写成可复查的门闩。一次漂亮的回答仍可欣赏；交付与发布，则应更相信闸门、日志与回滚，而不是相信「它这次看起来很懂」。
写到这里，并无意推荐某一厂商或某一框架。挽具可以很厚，也可以薄到只剩「改完跑测试、合并前等人点头」。重要的是承认：把力气很大的模型直接放进生产，而不给它缰绳，责任仍在人——只是失败会来得更喧闹。灯下记这一笔，是为了少一点对「更聪明」的迷信，多一点对「更稳妥」的耐心。