很多企业开始接入 Agent 之后，会产生一个很自然的想法：项目的信息不是都在群聊里吗？那如果让 Agent 把相关群聊、会议纪要、邮件和文档都读一遍，它是不是就能自动知道项目进度？
这个设想听起来很合理。项目过程中确实有大量信息沉淀在这些地方。客户确认了方案，采购反馈某个物料缺货，技术说图纸需要重出，项目经理催了一次交付时间，某个问题在群里讨论了半天，最后有人说“那就按这个来”。
如果只是想知道“昨天大家聊了什么”，现在的大模型已经可以做得不错。真正麻烦的是另一个问题：这个项目现在到底进行到哪一步了？
假设群里有一句话：“客户已经确认了，可以往下走了。”
人看到这句话，通常不会只理解字面意思。我们会自动把它放回整个项目背景里：确认的是哪一版方案，之前卡在哪个环节，这次确认意味着什么，后面的设计、采购或者生产是不是因此可以启动，还有没有别的前置条件没有满足。
也就是说，我们理解的从来不只是一句话。
我们脑子里已经有一个关于这个项目的模型，所以能把这句话解释成一次状态变化。
Agent 的问题也在这里。
如果它只有聊天记录，那么它拿到的是一连串发生过的表达，却未必拥有一个稳定的“项目”可以把这些表达放进去。它可以总结出“客户确认了方案”“某物料延期”“交付时间可能受影响”，但这些信息究竟对应哪个对象，改变了什么状态，又会继续影响哪些事情，并不会因为文本读得足够多就自动变得清晰。
这也是为什么“给 Agent 更多上下文”并不能完全解决问题。
上下文解决的是信息有没有被看到，而项目进度是另一个层面的问题。它需要系统知道项目由哪些对象组成，现在分别处于什么状态，它们之间有什么依赖，什么事件会让状态发生变化。
否则，今天让 Agent 总结一次项目进度，明天再总结一次，得到的很可能只是两篇都很通顺的文字。人可以勉强从中比较发生了什么变化，但系统本身并没有真正维护一个持续演化的项目状态。
群聊因此更像是现实运行过程中不断产生的信号，而不是项目本身。
真正稳定的东西，应该是项目、任务、需求、问题、里程碑以及它们之间的关系。聊天记录可以帮助 Agent 发现“刚刚发生了什么”，但这些变化最终还是需要落到一个更稳定的结构里，才能成为“现在是什么状态”。
于是问题就从“Agent 能不能把所有信息读完”，变成了另一个更基础的问题：
企业有没有一种方式，能够持续表征自己正在发生的业务世界？
这也是为什么我越来越觉得，在讨论 Agent 之前，必须先讨论“表征”。