阿里殺進Agent上下文戰場：釘釘聊天、企業文檔、工作數據終於要被Agent吃進去了

這產品那插件用了大一圈，我這Agent咋還是不懂我日常每天的工作流啊…… 哪怕到了各種Harness各種AI產品滿天飛的今天，個人、企業用戶依然苦工作場景「上下文」久矣。對於真實工作裡最重要的信息，Agent經常兩眼一抹黑！！在釘釘裡跟同事聊過啥、文檔裡沉澱過哪些決策、企業各種標準規範，這些數據信息往往全散落在Agent之外。那如果我說，現在有這麼個東西，能直接給每個人建一層專屬的工作上下文呢—— 聊天、文檔、會議裡散落的歷史信息，全給你收攏整理成Agent能直接消費的上下文。甚至我再打眼一看，這個項目開源短短一週，就已經在GitHub斬獲超1k Star了！？

不賣關子，就是這兩天阿里千問辦公開源的上下文基礎設施「MyContext」。這玩意兒乾的事情，可以說是相當《直給》—— 直接把分散在各處、格式各異的個人工作數據加工成Agent能理解的專屬檔案，讓Agent真正讀懂用戶和真實業務工作流，並最終在決策和執行等環節實現人機協同。而且MyContext一上來挑的，還是企業上下文裡幾塊出了名難啃的骨頭。遲到、反覆變化的時序數據，彼此矛盾的事實，以及海量歷史數據持續更新帶來的計算成本，基本一起梭哈了。當聊天、文檔、會議和業務規則都能被持續加工成Agent可消費的上下文，Agent才真正有機會從一個會執行指令的工具，走進真實工作流。

這回，真的有人幫我們把真實業務場景裡的數據信息，狠狠加工利用起來了！！從分散數據到可用上下文，MyContext補上Agent的數據加工層 Agent Harness，幾乎成了今年AI圈繞不開的關鍵詞。這邊模型的推理、代碼和工具調用能力不斷next level。那邊各種插件、協議和執行框架不斷補齊Agent的任務編排、環境調用、多步執行和狀態管理能力。於是到了今天，Agent處理個人辦公任務，已經越來越像那麼回事了： 寫報告、查資料、改表格、跑代碼，甚至連續執行一串複雜任務，都已經逐漸進入能用好用的階段。

But，一旦把它真正塞進工作流，一個扎心的問題還是會迅速冒出來—— 這Agent，是真不懂真實業務場景啊我說！！！舉個大家日常工作裡應該都很有體感的例子。我們讓Agent幫我把上週討論的客戶方案更新一下，再按公司最新口徑整理成彙報資料。這句話對人來說信息很完整，但對Agent來說，這些真實業務中的內容可能天然分散在郵件、IM、文檔和各種數據庫中，甚至可能還伴隨著實時更新、版本衝突、權限邊界與信息過期的問題。結果就是Agent既不懂咱的工作流，也不瞭解企業內部規範，只能靠模型通用知識和當前Prompt完成當前任務，真·傻眼了。

而這，也恰恰暴露出Agent走向生產級場景時一個越來越核心的上下文問題。模型能力一路提升，並不會同步補齊Agent對真實工作場景的理解。真實工作從來都不是一條孤立指令，每一個任務背後都掛著散落在不同平臺中的工作討論、已經形成的決策、不斷變化的狀態、組織內部的規則，以及人與人之間默認已經知道的上下文背景。這些持續積累、不斷變化的信息，共同構成了一個任務真正的「業務現場」。這些業務信息一旦無法進入上下文，Agent就只能更多依賴通用知識和當前指令，無法真正嵌入具體工作流。

更扎心的是，這個問題甚至已經逐漸成為Agent進入生產級場景的普遍基礎設施瓶頸—— Confluent 2026年調查顯示，66%的企業認為數據基礎設施和數據質量正在拖慢Agentic AI落地；與此同時，80%的企業已經把「用好自家數據驅動AI」列為業務優先事項。換句話說，企業AI落地真正卡住的，已經不再是前端有沒有更強的模型的問題，而是後端有沒有一套能把分散業務數據持續治理、加工並轉化為可用上下文的「基礎設施」。好在，這個問題已經開始有主流廠商從基礎設施層動手了。

針對Agent吃不到真實業務上下文這個bug，阿里千問辦公最近開源的項目「MyContext」給出的解法相當直給—— 直接把那些原本散落在Agent視野之外的工作數據資料，加工成Agent真正能消費的上下文。IM裡的溝通、文檔、會議、業務協作記錄，以及本地和其他工作數據源裡的信息，都可以經過用戶授權，被持續收攏、整理，再逐步沉澱成一份動態更新的工作檔案。過去那些每次都得反覆交代給Agent的工作流信息背景—— 你在負責什麼、經常和誰協作、項目最近發生了什麼、哪些討論已經形成結論，這回可以被系統性保留下來，並直接進入後續任務執行鏈路。不僅如此，MyContext沒有把上下文做成一團「黑箱記憶」。

每條結論都保留了可追溯的證據鏈，可以繼續點回原始聊天、文檔或會議記錄，確認是誰、在哪天、具體說了什麼；同時，Agent能夠看到和調用的信息，也始終受用戶與組織權限約束。這樣一來，個人用戶最直觀的變化，就是不用每換一個Agent都重新自我介紹一遍。對企業來說，也可以將群聊、文檔、會議裡那些「人都知道，AI不知道」的隱性業務背景，集成到Agent的工作鏈路。一言以蔽之，真實工作裡的經驗、工作流，都能被系統性加工成AI可理解、可檢索、還能直接用於執行的Context了～ 把動態、衝突、異構數據，處理成Agent可消費的可信上下文 針對企業級上下文的問題，海外廠商其實已經展開了不同路徑的探索。

比如，企業級數據與AI平臺公司Palantir，通過Ontology來統一企業對象、關係與業務邏輯，給Agent提供可執行的語義層。企業級AI搜索與知識平臺公司Glean則更強調Enterprise Graph，把人、項目、文檔和業務實體之間的關係連起來。微軟則依託Microsoft Graph與Copilot Connector，把企業數據、權限和協作關係接入Copilot。幾條路線雖然不同，但方向是一致的，那就是Agent要進入企業核心流程，必須先建立對組織數據、關係和規則的上下文理解。

但在企業上下文這條技術路線上，從早期就瞄準企業場景的千問辦公團隊，又進一步把關注點推向了更底層的問題—— 如何把異構、強時序、持續變化，甚至彼此衝突的原始業務數據，穩定加工成Agent可以直接消費的Context。△AI生成 在千問辦公團隊看來，上下文真正接入業務場景之後，難點遠不止把數據接進來這麼簡單，其背後真正需要解決的，其實是一整套圍繞數據處理、狀態管理與上下文推理的工程問題。一個很典型的問題，就是「時間」。真實辦公數據裡的時間，遠比一個時間戳複雜，上週的消息可能今天才同步進來，同一個群上午聊上線、下午聊預算，也已經是兩個不同話題。

如果只按時間先後篩選，遲到信息容易被漏掉；機械按固定Token切分，又可能把不同話題混進同一段上下文。針對這個問題，MyContext並沒有簡單按「時間新舊」處理數據，而是給每條原始信息綁定一個穩定的來源標識—— 將冪等性建立在數據源的穩定標識之上，即使時間戳已經很舊，只要系統此前沒有消費過，數據依然會進入處理鏈路；同時以對話空閒間隔作為Session邊界，讓上下文切分服從真實交互節奏。在更高一層的知識提煉環節，它還採用滑動時間窗持續聚合證據，某個事實如果在不同時間、不同討論中反覆出現，其重複本身就會轉化為新的置信度信號。

這樣一來，Agent看到的就不再是一堆按時間排列的聊天記錄，而是一套能識別新舊、保留話題邊界、處理歷史更新，還能隨著時間不斷校準可信度的動態上下文～ 另一個更棘手的問題，是「事實衝突」。企業裡的工作事實很多時候並不會整整齊齊地排成一條線，銷售說客戶已經確認，項目經理卻說流程還沒走完；上午會議裡定了A方案，下午負責人又補充了新的條件。工業系統裡常見的處理方法，是保留最新版本，或者保留置信度最高的一條，看起來得到了唯一答案，實際也順手抹掉了決策過程裡的分歧和變化。

在這點上，MyContext則通過「三態合併機制」把衝突當成一種需要保留的業務信號—— 一致信息用於增強置信度；補充信息併入既有結論；出現真實衝突時，則同時保留多條事實並下調置信度，將衝突顯式暴露給用戶。對於已經由用戶人工確認的結論，則進一步設置更高優先級，禁止後續模型自動覆蓋。這就意味著，Agent拿到的上下文，會更接近真實組織運轉的狀態，哪些事情已經形成共識，哪些還在變化，哪些必須等人拍板，它都能分得清。△AI生成 最後一個很容易被忽略的問題，是上下文工程本身也得算得起《賬》。大家都知道，企業數據是持續更新的，如果每來一批新消息，就讓模型把歷史上下文從頭算一遍。

如果每來一批新消息，都重新做Embedding、實體判斷、去重和歸併，計算成本和延遲很快就會失控，真·燒錢啊！！！於是乎，MyContext靈機一動，選擇把重點放在增量計算上—— 能靠本地規則判斷的先直接處理，只有碰到關係模糊、規則拿不準的信息，才交給模型；已經算過的結果儘量複用，多次更新則攢成批次集中處理。再配合版本緩存、批量觸發和分級降級策略，儘量減少重複計算，把昂貴的模型能力留給真正新增、真正需要推理的信息。於是，一套能夠持續處理異構數據、時序狀態、事實衝突、置信度演化、增量計算與成本約束的系統工程，就這麼集達成到了MyContext身上。

而這些看不見的底層功夫，也決定了Agent能否從偶爾調用幾個工具完成任務，進一步走進持續變化的真實業務流程，長期、穩定地幹活。從組織數據到Agent協作，補齊企業上下文最後一環 企業每天最鮮活的上下文，本來就產生在一線協作現場。自誕生起便瞄準企業工作場景的千問辦公，顯然很早就意識到了這一點。而作為面向真實業務場景搭起的上下文基礎設施，MyContext事實上也沒有把能力邊界停留在個人用戶身上。再往前一步，它所瞄準的更大命題，是把這套上下文能力從個人工作流繼續向組織內部延伸—— 與釘釘、千問辦公形成一套「數據匯聚—上下文加工—Agent消費」的三位一體閉環，真正進入企業級工作場景。

在IM層面，釘釘擁有國內最大規模企業客戶，覆蓋超2000萬企業組織、近8億用戶，是天然的數據入口，企業可快速從中獲取高價值原始知識庫。到了Context治理層，千問辦公團隊在異構數據處理和上下文工程上的積累，則可以幫助企業把釘釘、飛書、Salesforce、SAP，以及企業本地存儲裡那些原本各說各話的知識、工作流等重新組織起來。在Agent層，千問辦公承接高質量上下文，推動任務執行從「能完成」走向「更準確、更符合組織規則」。

這三層連起來之後，企業過去分散在不同系統裡的數據，才真正完成了一次價值躍遷—— 那些藏在聊天記錄、會議紀要、業務系統和個人判斷裡的信息，不再隨著項目結束、人員流動和時間推移一點點下沉，而是逐漸沉澱為一套可信、可追溯、還能隨著組織運行持續演化的工作上下文。當這層能力真正建立起來，Agent才有機會從一次次被動接收Prompt的工具，進一步演化為能夠理解組織、延續任務、參與協作的長期生產力單元。這也意味著，真實業務場景裡的數據也將從「可被查詢的資產」進一步走向「可參與執行的資產」。對了，目前MyContext已經開源，感興趣的朋友可以直接上手試試～ 參考鏈接： [1]https://github.

com/openTrinity/mycontext#mycontext 版權所有，未經授權不得以任何形式轉載及使用，違者必究。