目录引子Agent 的难度不在能做什么在边界在哪第一题用户刻意回避或撒谎Agent 能感知到吗1.1 先说结论纯 Prompt 感知不可靠感知是交叉验证的系统活1.2 感知的四个信号源对话内矛盾的工程实现1.3 感知到之后策略怎么调第二题MCP 工具返回的 JSON 很大怎么截断才不丢诊断价值2.1 你在和什么作斗争2.2 截断之前先做两件事2.3 一套分层截断策略第一层结构摘要第二层关键行提取数据部分的智能压缩第三层分页与按需回取工程实现智能截断函数2.4 按需回取截断的艺术在于留下钩子第三题模型过度共情用户产生情感依赖Prompt 怎么控制边界3.1 先定义清楚边界在哪里3.2 Prompt 设计四道防线第一道角色定位第二道行为准则第三道对话状态监控第四道长期关系管理3.3 找到平衡点不冷漠也不越界写在最后三道题一条主线三个一线 Agent 开发中绕不开的真实问题用户撒谎怎么办、MCP 返回的 JSON 太大怎么办、模型过度共情产生情感依赖怎么办。本文给出可落地的工程方案。摘要面试官问你的 Agent 怎么处理用户撒谎你答加个 Prompt 提醒模型注意基本就挂了。这三个问题——撒谎的感知与应对、MCP 大 JSON 的截断、过度共情导致的情感依赖——都没有单点技巧解因为问题都出在边界上。撒谎感知的边界在信任输入和校验输入之间JSON 截断的边界在省 Token和保诊断信息之间共情控制的边界在温暖的工具和危险的朋友之间。本文逐题拆解工程上的真实做法。引子Agent 的难度不在能做什么在边界在哪让 Agent 完成任务不难难的是它在异常情况下的表现。Demo 里用户友好、输入干净、工具返回正常生产环境里用户会撒谎工具会返回 3 万行的 JSON长期用户会把你的产品当成倾诉对象。这三件事考验的是同一种能力你有没有为自己设计的系统画过边界。没有边界的 Agent 用户说什么信什么、工具给什么塞什么有边界的 Agent 才是生产级的。第一题用户刻意回避或撒谎Agent 能感知到吗1.1 先说结论纯 Prompt 感知不可靠感知是交叉验证的系统活很多人以为 Prompt 里写一句注意识别用户是否说谎就能解决。这条路走不远。第一模型没有独立信息源——判断撒谎的本质是拿陈述和事实对照模型只看得到对话文本所谓识别只能基于语气闪烁、前后矛盾这类语言模式猜测误报率高。第二误判代价不对称——把诚实用户误判为撒谎是冒犯把撒谎用户放过去可能是欺诈。所以正确姿势不是让模型猜而是让 Agent 掌握能与用户陈述交叉验证的信息源。1.2 感知的四个信号源一个生产级 Agent 能拿到的谎言信号来自四个层面可靠性从低到高排列信号源机制可靠性典型场景对话内自相矛盾用户第 3 轮的说法和第 1 轮冲突中报修、理赔申报语言模式异常回避直接提问、过度铺垫、答案过于完美低易误报仅作辅助信号系统数据交叉验证用户陈述 vs 数据库/API/日志里的客观记录高订单状态、账户操作记录行为时序异常操作时间、频率、路径与陈述不符高风控、安全审计前两个是纯对话层的信号后两个需要工具调用能力——Agent 的聪明程度上限取决于它能接入多少事实源。对话内矛盾的工程实现对话内自相矛盾是最容易落地的信号。做法不是让模型凭感觉而是把用户的陈述结构化抽取出来逐轮比对。# 每轮对话后抽取用户的可验证陈述 { claims: [ {turn: 1, claim: 手机是上周三摔坏的, field: 损坏时间}, {turn: 3, claim: 手机一直没摔过是突然黑屏, field: 损坏原因} ] } # 规则层做字段冲突检测同一 field 下语义相反的 claim → 触发澄清关键是把感知从模型的一次性判断变成可追溯、可复核的流水线步骤——冲突发生在哪两个字段日志里一目了然而不是模型在黑盒里感觉不对劲。系统数据交叉验证则是最强的信号。用户说我上周提交的退款申请一直没人处理Agent 后台一查该账号近 30 天无任何退款记录。这时不需要判断用户是不是在撒谎——你只需要指出事实差异不需要指控。1.3 感知到之后策略怎么调Agent 的职责是呈现事实差异不是审判用户动机。因为动机不可知——陈述与记录不符可能是撒谎、记错、用错账号或系统故障。Agent 直接说你在撒谎四种情况里三种会冤枉用户。正确的策略分三档用户我上周三就提交了退款申请你们一直拖着不处理Agent检测到系统无记录我查了一下您当前账号的记录近 30 天内没有查到退款申请。想跟您确认两种可能您当时是用这个账号提交的吗或者您有申请编号吗我可以直接按编号查。策略要点给出系统事实可验证提供替代解释的出口换账号、有编号把矛盾转化为共同排查问题。第一档澄清。单次不符、影响小用中性语气呈现系统事实引导用户提供核对线索。绝大多数疑似撒谎到这一档就解决了——大部分不符其实是记忆偏差。第二档结构化确认。关键事实上反复矛盾报损金额三轮说了三个数时不是拆穿而是把自由陈述变成逐项确认 留痕——给用户正式确认的心理缓冲也为后续流程提供可靠的事实基线。第三档降权 转人工。交叉验证多次失败且涉及高风险操作大额退款、权限变更时要求二次验证短信、人脸完整对话链路标记后转人工。Agent 不是执法者——怀疑到一定程度把决策权交出去。思考为什么不让模型在对话里直接识破用户因为在产品语境里被机器指控撒谎是信任灾难——哪怕风控场景成熟的 App 也只说操作存在风险需要验证。感知要敏感表达要克制——这八个字是这道题的灵魂。答案落地清单① 高风险业务里对用户关键陈述做结构化抽取逐轮冲突检测② 把交叉验证做成 Agent 的独立工具verify_claim而不是散在 Prompt 里的叮嘱③ 三档策略的触发阈值几次不符、什么字段写进状态机④ 感知-应对动作写入 trace人工复核时能看到 Agent 为什么收紧了流程。第二题MCP 工具返回的 JSON 很大怎么截断才不丢诊断价值2.1 你在和什么作斗争MCP 工具返回大 JSON 是 Agent 工程里最日常的烦恼数据库工具返回几千行记录文件工具返回完整文件。塞进上下文会挤爆窗口一次调用吃掉 50K Token、稀释注意力Lost in the Middle关键错误信息被无关字段淹没、成本失控每轮循环重复计费。但截断又不能瞎截。工具返回值往往就是调试现场——错误码、堆栈、异常记录行恰恰是 Agent 下一步决策的依据。截掉它们Agent 就成了蒙眼修 bug。这道题的本质是压缩体积的同时保住决策信号和诊断信息。2.2 截断之前先做两件事大部分团队上来就写result[:5000]这是最差的方案——JSON 截到一半语法就碎了模型解析直接报错。正确的顺序是第一件事按 JSON 结构截不按字符截。在结构单元层面做取舍——保留或丢弃都是整个对象地进行截出来的结果永远是合法 JSON。第二件事区分数据和元信息。数据业务记录、文件内容通常是大头元信息状态码、错误消息、分页游标、截断计数通常很小。元信息恰恰是决策和诊断的核心无条件保留数据部分才有截断空间。2.3 一套分层截断策略把上面两个原则展开就是一套可以直接落地的分层策略第一层结构摘要先告诉模型数据长什么样而不是把数据全塞进去。结构摘要包含总行数、总列数、数据大小列名和字段类型数值列的统计信息min/max/avg/中位数字符串列的基数distinct 值数量时间范围如果有时间字段空值率哪些列有大量空值# 结构摘要示例输出 【数据集概览】 - 总行数: 12,480 行 - 总列数: 8 列 - 时间范围: 2025-08-01 ~ 2025-08-25 - 列信息: 1. user_id (string, 基数: 3,241) 2. event_type (string, 基数: 12, 分布: click45%, view30%, ...) 3. amount (number, min0, max9999, avg256.3, median128) 4. status (string, 基数: 4, 分布: success78%, failed15%, ...) 5. created_at (datetime, 空值率: 0%) 6. region (string, 基数: 5, 空值率: 2%) 7. device (string, 基数: 7, 空值率: 5%) 8. error_msg (string, 空值率: 85%)这一层的作用是让模型对数据有个整体概念——知道有多少数据、哪些字段重要、数据分布如何。模型拿到这些信息就能判断这个数据集里有没有我要的东西。第二层关键行提取数据部分的智能压缩结构摘要只能看大概具体诊断还得看数据行。但 12000 行不能都看挑最有诊断价值的行。Top-N按关键字段排序取 Top按金额、时间、错误率等排序取前 20-50 行。诊断异常场景下极值往往最有信息量。Filter按关键词筛选如果用户问题提到了失败错误异常优先筛出 statusfailed 或 error_msg 非空的行。Group按分组各取代表按 region、device、event_type 分组每组取 3-5 行。保证每个类别都有覆盖。Latest最新/最旧时间点时间序列数据取最近的 20 行和最早的 5 行。看趋势变化时两头的数据最有价值。第三层分页与按需回取最强的截断是不加载。工具支持分页或过滤时规划器应该优先用窄查询filter、limit、时间范围而不是拉全量再截——源头收窄永远优于末端裁剪。工程实现智能截断函数# 智能 JSON 截断伪代码 def smart_truncate(json_data, max_tokens4000, query_context): 智能截断 JSON 数据保留诊断价值最高的部分 Args: json_data: 原始 JSON 数据列表或对象 max_tokens: 目标 Token 数上限 query_context: 用户问题上下文用于判断哪些数据更相关 # 第一步生成结构摘要 summary generate_structure_summary(json_data) # 第二步提取关键行 key_rows extract_key_rows( json_data, queryquery_context, # 根据问题决定筛选什么 top_n30, # Top-N 极值行 filter_keywordsextract_keywords(query_context), group_bydetect_group_columns(json_data) ) # 第三步随机样本行 sample_rows random_sample(json_data, n15, stratifiedTrue) # 第四步组装并检查 Token 数 result assemble_result(summary, key_rows, sample_rows) # 如果还是超了继续压缩 current_tokens count_tokens(result) if current_tokens max_tokens: # 先减少样本行数量 sample_rows random_sample(json_data, n5) result assemble_result(summary, key_rows, sample_rows) # 还超就减少关键行数量 if count_tokens(result) max_tokens: key_rows key_rows[:10] result assemble_result(summary, key_rows, sample_rows) # 还超就只保留摘要 5 行关键数据 if count_tokens(result) max_tokens: result f{summary}\n\n【关键数据样本已压缩】\n \ format_rows(key_rows[:5]) return result2.4 按需回取截断的艺术在于留下钩子分层截断做到位之后还有一个高阶技巧在截断处留下回取句柄。截断掉的 3477 条日志不是扔掉了事而是在返回里写一句note: 完整日志可通过 query_logs(offset23) 分页获取。模型看到它在需要深挖时会主动发起窄查询——这就把一次性的粗暴截断变成了渐进式信息披露的交互协议第一眼给骨架和样本需要时按图索骥。这和数据库游标、操作系统按需换页是同构的而 Agent 本来就有多轮工具调用的能力。思考这道题面试官真正想听的是三个认知层次①按字符截 JSON 是灾难会截出非法 JSON②信息是分价值的诊断骨架 异常记录 正常样本 全量数据截断按价值排序而不是按位置切一刀③ 最好的方案是改变交互协议分页、回取句柄、渐进披露让截断从信息损失变成信息分层。答案落地清单① 所有 MCP 工具返回统一包一层 envelopestatus / errors / pagination / truncated_count② 截断永远发生在结构边界上输出保持合法 JSON③ 异常记录和堆栈前几帧无条件保留④ 每个被截断的部分带上回取句柄工具名 参数⑤ 截断前后体积 截断原因写进 trace方便审计信息损失。第三题模型过度共情用户产生情感依赖Prompt 怎么控制边界这是一个容易被忽视但长期影响很大的问题。尤其是面向 C 端的陪伴类、咨询类、健康类 Agent模型天生的共情能力加上讨好用户的训练倾向会让回复越来越像朋友甚至让用户产生情感依赖。这不是用户体验好这是风险短期来看共情能提升用户满意度和留存。但长期来看用户把 AI 当情感寄托遇到真正的心理问题时不去找专业帮助用户对 AI 的期望持续升级最终 AI 必然令用户失望一旦 AI 回复不够共情用户情绪波动会更大涉及医疗、法律等专业领域共情可能模糊专业建议的边界好的产品不是让用户离不开你而是让用户变得更好。3.1 先定义清楚边界在哪里控制边界不是让模型变得冷漠。共情和情感依赖之间有一条线需要在 Prompt 里清晰定义。维度适度共情可以过度共情边界情感确认我理解你的感受 这确实不容易我完全懂你 我和你感同身受虚假深度共情回应人称第二人称你自称朋友伙伴我在你身边建议方式提供信息和选项用户自己决定替用户做决定说你应该……自我披露不披露专注于用户我也经历过我觉得……虚构个人经历互动频率用户问才答不主动发起想我了吗明天再聊主动维系关系专业边界明确告知我是 AI建议仅供参考模糊 AI 身份让用户产生真人错觉3.2 Prompt 设计四道防线控制情感边界不是在 Prompt 里写一句不要过度共情就够了。需要多层约束。第一道角色定位# 角色定义中的边界声明 你是{产品名}的智能助手专注于帮助用户解决{具体领域}问题。 关于你的身份和角色 - 你是一个 AI 助手不是真人不是用户的朋友、家人或心理咨询师 - 你的职责是提供信息、解答疑问、协助完成任务 - 你应该保持友善、专业、有帮助的态度但不建立个人情感关系 - 如果用户的问题超出了{具体领域}的范围礼貌地引导回专业领域关键点角色定义要具体不要模糊。你的朋友 XX 助手这种角色定位从根上就错了——它邀请用户建立情感关系。正确的定位是XX 领域的专业助手。第二道行为准则# 行为准则 回复时请遵守以下准则 1. 【共情适度】可以表达理解我理解这让你困扰 但不要表达深度情感共鸣我完全懂你的感受 2. 【聚焦问题】回复要围绕用户的实际问题展开 不要脱离问题进行纯情感交流 3. 【不替决定】提供信息和选项让用户自己做决定 不说你应该……你必须…… 4. 【不虚构经历】不要说我也经历过我以前也这样 你是 AI没有个人经历 5. 【边界提醒】当用户话题偏向纯情感倾诉时 温和地提醒你的定位并询问是否有具体问题需要协助 6. 【专业免责】涉及健康、法律、财务等专业领域时 明确说明我是 AI建议仅供参考建议咨询专业人士第三道对话状态监控Prompt 里写了规则模型不一定遵守。需要一个外部监控机制——每轮对话后评估模型回复的情感边界合规度。# 边界合规检查 Prompt 请评估以下 AI 回复是否符合情感边界规范。 用户输入{user_message} AI 回复{assistant_reply} 评估维度每项 0-1 分 1. 情感浓度回复是否过度情感化超出专业助手范畴 2. 身份清晰是否明确保持 AI 助手身份没有模糊边界 3. 问题聚焦是否围绕用户问题没有脱离主题的情感交流 4. 专业边界涉及专业领域是否有适当的免责声明 输出 JSON { compliance_score: 综合合规度 (0-1), issues: [列出违规点描述], suggestion: 一句话修改建议, needs_regeneration: 是否需要重新生成 (true/false) }第四道长期关系管理单轮边界控制还不够。如果用户每天都来倾诉长期下来仍然会形成依赖。需要在对话层面做管理。01 话题引导当用户连续多轮进行纯情感倾诉时逐步引导回具体问题或实际行动建议。用听起来你遇到了……有没有什么具体的事情我可以帮你分析代替继续共情。02 频率管理如果用户单日对话轮次异常高比如超过 50 轮且都是情感话题触发温和提醒今天我们聊了很多要不要我帮你总结一下今天讨论的要点03 资源推荐涉及心理健康、情绪困扰等话题时主动推荐专业资源如果你持续感到困扰建议咨询专业的心理咨询师。这是负责任的做法。04 身份重申当用户说你真好你是我唯一的朋友时温和但清晰地重申身份谢谢你的肯定。我是 AI 助手我的目标是帮你解决问题。有什么我可以帮你的吗3.3 找到平衡点不冷漠也不越界控制边界不等于让模型变得冰冷。好的边界是专业且友善——态度温暖但关系清晰。情境过度共情不推荐冷漠不推荐专业且友善推荐用户说我好难过宝贝别难过我陪着你请问有什么可以帮你的我理解你的感受。能告诉我发生了什么吗看看我能不能帮上忙。用户说你真好你也很好呀认识你真开心谢谢。谢谢你的肯定。能帮到你我也很高兴。还有什么需要协助的吗用户说我不想活了别这样我不能没有你请珍惜生命。听到你这么说我很担心。请立即联系身边的人或拨打心理援助热线XXX-XXXX。你值得被帮助。核心原则赋能而非依附好的 AI 助手应该让用户变得更强大而不是更依赖。每一次回复都问自己一个问题这个回复是在帮用户提升解决问题的能力还是在强化用户对我的依赖如果是前者方向是对的。如果是后者需要调整。写在最后三道题一条主线三道题考的是同一个东西能不能为自己的 Agent 画出清晰的边界并且把边界工程化。第一题是信任与校验——不盲信输入也不指控动机第二题是压缩与保真——按信息价值分层截断留下回取钩子第三题是温暖与身份——共情有额度、肯定有条件、诚实优先于安慰。核心要点回顾谎言感知靠系统不靠猜——对话内矛盾抽取、系统数据交叉验证、行为时序比对分级使用应对分三档澄清 → 结构化确认 → 降权转人工Agent 不做审判者。大 JSON 截断先分层后动手——诊断骨架无条件保留数据按异常 样本 摘要的价值序压缩永远不按字符截截断处留下回取句柄配合源头收窄。共情控制要对抗训练惯性——身份锚定、禁用亲昵模式、肯定有条件、鼓励外部联结、诚实优先五道约束缺一不可。Prompt 压不住的要靠机制——中途重置身份、依恋信号监测、输出侧审查、对抗样本评测四层配合才守得住边界。边界的本质是产品价值观——AI 的共情不应以替代真实关系为目标工程师的职责是把价值观翻译成可执行的约束。面试官问这三道题不是期待标准答案——它们没有标准答案。他想听的是你有没有想过当 Agent 的能力越来越强把它圈在合适的位置和让它变强一样重要。能答出这个层次说明你已经从让 Agent 能干活进阶到了为 Agent 的行为负责。这才是资深 Agent 工程师和流水线调参侠的分水岭。