为什么上下文越长，Agent 不一定越聪明？
在业主关系管理中，同一句“这笔费用为什么不一样”，可能来自不同身份、不同项目、不同合同状态和不同沟通阶段。只看问题文本，模型可以生成一段听起来合理的解释；如果看见的是错误项目、过期规则或不属于当前操作者范围的记录，回答越完整，反而越可能把沟通带向错误方向。
因此，上下文的价值不等于字数。无关历史会稀释注意力，过期事实会制造冲突，缺少时间和组织边界的数据会让模型错误拼接不同业务对象。即便上下文窗口足够长，把“可能有用”的内容全部加入，也只是把筛选责任转移给模型，并没有消除筛选问题。
Anthropic 在上下文工程文章中将上下文视为模型推理时可用、但有限的 token 集合，并提出一个重要的工程目标：寻找能够最大化预期结果概率的最小高信号信息集合。这是通用 Agent 工程观点，不意味着某一种裁剪方式适用于所有物业任务；它提示我们，注意力本身就是需要分配的有限资源。
上下文工程与提示词工程有什么不同？
提示词工程主要解决“怎样把任务说明清楚”：模型扮演什么角色、遵循哪些原则、应该输出什么。上下文工程解决的是更大的问题——在每一次推理发生前，系统如何选择和维护模型此刻能够看见的完整状态。
这份状态不仅包含提示词，还包含工具说明、业务事实、消息历史、知识来源、上一阶段结果和任务当前状态。随着 Agent 读取新信息、调用能力并推进任务，上下文会不断变化。因此，提示词更像一份相对稳定的工作说明，而上下文工程是一项伴随任务持续发生的选择工作。
对企业 Agent 而言，两者缺一不可。提示词不清楚，模型不知道如何工作；上下文不正确，模型会在错误的业务现场里认真工作。LIGOWIN 更关注后一个问题，因为物业业务中的身份、项目、时间和证据边界，不能只靠一段自然语言提醒来保证。
真实的物业业务现场由什么组成？
业务现场不是一份静态客户档案，而是一组围绕当前任务成立的关系。一次费用异议可能需要关联业主身份、房屋和合同、所在项目、适用时段、历史服务记录与沟通承诺；一次运营分析则需要不同的对象、指标口径和组织范围。上下文是否有效，取决于这些关系能否同时成立。
我们把物业 Agent 需要理解的现场概括为六个维度。它们不是要在每个任务中全部展开，而是帮助系统判断当前缺少什么、应该排除什么，以及哪些信息只能在特定权限下出现。
身份与权限
谁在发起任务、代表何种职责，以及哪些信息和动作属于其授权范围。
目标与对象
当前要解决什么问题、处理哪个业主或业务对象，以及什么结果才算完成。
组织与范围
事实属于哪家企业、哪个项目或协作单元，避免跨范围信息相互污染。
时间与状态
哪一个时间窗口有效，当前流程进行到哪里，哪些历史已经过期或被新事实替代。
历史与证据
与当前判断直接相关的沟通、服务记录、指标和可回溯来源。
可用能力
当前任务允许读取、分析、建议或执行什么，并明确哪些决定必须交还给人。
这里最容易被忽略的是：权限、时效和适用范围不是附加元数据，它们就是事实含义的一部分。同一条记录对不同角色可能具有不同可见性；同一项规则跨越不同地区和时间可能不再适用；同一段历史如果已经被后续处理结果覆盖，也不能继续作为当前结论的唯一依据。
如何把上下文做成独立的业务能力？
一种常见做法，是让应用临时查询若干数据，再把结果直接拼进提示词。它适合验证想法，却容易把业务范围、数据整理和模型推理耦合在一起：换一个任务就复制一次，业务口径改变时也很难判断哪一段上下文仍然有效。
LIGOWIN 的设计选择，是把“还原现场”从模型推理中分离出来。系统先依据任务身份、业务对象和时间范围取得候选事实，再完成筛选、聚合、裁剪与语义归一；模型接收的是已经明确范围的任务状态，而不是整个业务系统的原始数据集合。
这套分工有三个意义。第一，确定性程序负责访问范围和基础校验，模型不用猜测自己面对的是谁的数据；第二，不同任务可以复用同一类业务现场，而不必复制数据整理逻辑；第三，来源事实与模型生成的中间判断保持区分，后续流程能够知道哪些信息可以核验，哪些仍只是推断。
对业主沟通而言，这种设计并不直接保证回答正确，更不代表系统可以替代物业人员确认责任和费用口径。它提供的是一个更清楚的判断基础：同一个任务中的参与者围绕相同对象、相同时间和相同证据继续协作，有助于减少信息错位对业主信任的损耗。
信息不足时，为什么停止也是正确结果？
上下文工程不仅决定模型看见什么，也决定什么时候不应该继续。企业业务最危险的失败，不一定是系统报错，而是关键事实缺失时，模型用语言流畅度把空白填成了看似确定的结论。
因此，LIGOWIN 不把所有中止都归为笼统的“生成失败”，而是区分它们代表的业务含义。只有原因可识别，系统才知道下一步应该补数据、核实证据、调整任务，还是把判断交给人。
没有数据
目标对象或必要记录不存在，系统应回到数据补充或对象确认，而不是继续推理。
没有有效信号
存在记录，但在当前时间和业务口径下不足以支持判断，应说明缺少哪类有效事实。
证据不足
模型可以提出假设，却不能把假设写成结论；高影响事项需要补充证据或交由人员核验。
没有可用产出
模型返回为空或不符合结果要求时，应保留失败状态，避免用不完整内容继续触发后续动作。
上下文工程如何与物业知识库协作？
知识库与上下文工程经常被混为一谈。两者都在帮助模型获得外部信息，但回答的是不同问题：知识库回答“组织里有哪些可复用知识，它们来自哪里”；上下文工程回答“当前任务应该读取其中哪些知识，并与哪些业务事实共同使用”。
在 LIGOWIN 的物业知识库设计中，分层索引负责缩小知识范围，原始资料保留最终证据地位。上下文工程在此基础上继续加入当前任务的地域、时间、对象和权限条件，只把适用的知识与必要原文带入判断。这样，知识不会脱离业务现场被机械引用，业务记录也不会因为缺少领域规则而被孤立理解。
一个可以复用的概括是：知识库建设决定组织知道什么，上下文工程决定 Agent 此刻应该知道什么。前者沉淀长期领域资产，后者为一次具体任务分配有限注意力。两者结合，才能让业主沟通既贴近当前事实，又能够回到来源核验。
延伸阅读：我们如何构建高效、可信的物业知识库上下文工程的边界是什么？
上下文工程不能消除模型幻觉，也不能把不完整的数据变成完整事实。来源本身可能错误，业务范围可能配置不当，摘要和裁剪可能丢失细节，多轮任务中的中间判断也可能逐步偏离原始证据。更长窗口、自动摘要和长期记忆都只能改变信息管理方式，不能取消这些风险。
因此，高影响的费用解释、责任确认、对外承诺和数据变更，仍然需要明确规则、证据核验与人工控制。上下文可以帮助人员和 Agent 围绕同一业务现场协作，但业主信任最终来自真实服务、准确事实和负责任的沟通，不会由一种技术机制自动产生。
LIGOWIN 对上下文工程的站位也由此确定：它不是提示词之外的又一个技巧，而是把角色、组织、对象、时间、指标、知识和证据转化为可使用业务现场的基础能力。第一篇文章回答 Agent 如何从对话走向任务闭环；这一篇进一步回答，任务开始之后，Agent 凭什么知道自己正在处理此时、此地、此事。