问 headroom 是否在工作，其实是在问适配
“目前 headroom，已经适配了在工作了吗？”这句话看起来有点口语，甚至带着停顿，但它是很真实的人机协作问题。助手的回应是：“我来检查一下 headroom MCP 服务器当前的运行状态。”从表面看，这个回答合理；从协作角度看，它也暴露了一个常见分岔：用户问的是状态，还是适配？
素材里没有给出完整检查结果，所以不能编造 headroom 到底运行得怎样。但正因为事实有限，这个卡点更适合写成方法：当用户问一个工具“有没有在工作”，Agent 不应该只理解为进程是否启动，还要帮助用户拆开“工作”这个词。
运行状态不等于工作状态
很多工具都可能处在一种尴尬状态：服务是开的，命令能响应，日志也没有明显错误，但它并没有真正贴合当前任务。用户感到“不对劲”，往往不是因为工具完全坏了，而是因为它没有在正确的场景里发挥作用。
助手第一反应去检查 MCP 服务器运行状态，是符合工具诊断习惯的。可如果用户关心的是“适配了在工作了吗”，只看运行状态就不够。还要问：它是否已经接入当前协作流程？它的输入是否来自正确上下文？它的输出是否被后续任务使用？它解决的是现在的问题，还是只是作为一个可用组件挂在那里？
这就是人机协作里需要用户引导的地方。用户可以顺着 Agent 的检查继续走，也可以补一句：“我不是只问服务活没活，我想知道它是否适配当前工作流。”这句话会把诊断从机器状态推向协作状态。
“工作”这个词需要被拆开
对 Agent 来说，“工作”很容易被翻译成可执行、可连接、可调用。对用户来说，“工作”通常意味着有效、顺手、能帮上当前任务。两个理解不一样，就会出现回答看似正确、实际不够用的情况。
所以这类对话最有价值的动作，是把“工作”拆成几层。第一层是运行：服务器是否存在，连接是否正常。第二层是集成：它是否出现在当前工具链里。第三层是适配：它的能力是否符合当前任务。第四层是效果：用户是否真的因为它减少了上下文压力或提升了处理质量。
素材中的 headroom，本身就和上下文空间、压缩、取回这类工作有关。用户问它是否适配，背后可能是在问：这个工具有没有进入真实工作，而不是只被安装。Agent 如果只检查状态，就回答了第一层；用户真正需要的，可能是第二层到第四层。
判断链要从现象走向场景
当用户觉得工具“不太对”时，最容易提出一个模糊问题。Agent 如果急着给确定答案，反而可能错过真实需求。更好的判断链是先承认问题有多种含义，再逐层排查。
比如先说：我可以检查运行状态，但这只能证明它是否启动；如果要判断是否适配工作流，还需要看它在当前任务中的调用位置、输入输出和复用方式。这样回答，既没有回避用户问题，也不会把问题缩小。
用户也可以继续引导：“先看设计目标，再看当前使用点。”这会让 Agent 从结果检查转为流程检查。很多工具问题不是最后一跳失败，而是设计目标和使用场景已经错位。只看状态，永远找不到这种错位。
下次问工具是否有效，可以这样问
我会把这次经验变成一个提问模板：不要只问“它能用吗”，而是问“它现在在哪一层生效”。如果是 MCP 服务器，就问运行、连接、调用、输出、复用分别是否成立。如果是写作工具，就问它是否进入了选题、起草、校验、回收中的哪一步。
这种问法能让 Agent 给出更有用的回答。它不会只说“正常”或“不正常”，而会说明正常的是哪一层，未知的是哪一层。用户也能据此决定下一步：是修配置，还是改流程，还是重新定义工具职责。
headroom 这个小卡点提醒我，工具协作里最容易被忽略的不是安装，而是适配。一个工具在系统里存在，并不代表它在工作；它能响应，也不代表它对当前任务有效。用户要学会把模糊的不对劲说成可检查的问题，Agent 也要学会把“运行状态”放回“工作场景”里解释。
人机协作的思考艺术，有时就藏在这一句追问里：你检查的是机器活着，还是工具真的在帮我完成这件事？
让 Agent 说明检查范围
下一次再问类似问题，我会特别要求 Agent 先声明检查范围。它准备检查运行状态，还是检查工作流适配；准备看工具本身，还是看工具和当前任务之间的连接。这个声明很短，却能避免后面误会。用户听到“我先检查服务器状态”时，就知道这只是第一层，不会把它误认为完整结论。
这也是素材少时最稳的写法：不假装已经知道所有结果，而是把已知证据变成一套判断方法。headroom 是否适配，最终要靠具体环境确认；但“运行不等于有效”这个判断，可以先沉淀下来。它提醒我们以后评价任何工具，都不要只问它是否存在，而要问它是否真的进入了当前协作链条。