演講嘉賓｜向邦宇

編輯｜Kitty

策劃｜QCon 全球軟件開發(fā)大會

AI 發(fā)展過程中誕生了許多優(yōu)秀的 Coding 產(chǎn)品，但非專業(yè)開發(fā)者需要掌握一些簡單的研發(fā)知識才能完成研發(fā)任務，而這些工具和研發(fā)知識的匱乏，都在不同程度上影響非專業(yè)開發(fā)者的熱情。

本文整理自阿里巴巴高級技術專家向邦宇在 2025 QCon 全球軟件開發(fā)大會（上海站）的分享 “Vibe Coding 在代碼生成與協(xié)作中的實踐與思考”。主要探討如何構建下一代 Vibe Coding 工具，從阿里當前的挑戰(zhàn)出發(fā)，提出以用戶為中心、強化工具質(zhì)量、深化場景適配、支持協(xié)作與包容不確定性的核心設計原則與實踐。

內(nèi)容亮點

• Vibe Coding 工具在建設過程中遇到的問題，以及解決的辦法

• 構建 Vibe Coding 工具所趟過的產(chǎn)品方面的坑

• 構建 Vibe Coding 工具時的技術創(chuàng)新與落地實踐

以下是演講實錄（經(jīng) InfoQ 進行不改變原意的編輯整理）。

多年來，我一直在阿里巴巴內(nèi)部的技術研發(fā)設施平臺上從事研發(fā)者工具的工作，其中包括內(nèi)部的 AI 編程工具以及 Web IDE 工具等。從 2023 年開始，我參與了相關工作的轉(zhuǎn)型，從之前的內(nèi)部 Copilot 逐步轉(zhuǎn)向如今的 Agent 方向。

當我拿到這次演講選題時，我在思考 Vibe Coding 這一主題。雖然 Vibe Coding 已經(jīng)出現(xiàn)幾個月了，但它似乎還不是一個非常確定性的概念，因為大家對它的理解以及所使用的相關工具都存在差異。而我由于接觸了大量內(nèi)部用戶對這些工具的使用情況，包括他們在使用過程中遇到的問題，以及作為產(chǎn)品提供方，面對眾多用戶在使用工具時所遇到的問題，我需要思考如何解決這些問題。

首先，我會簡單介紹一下我們內(nèi)部在哪些行業(yè)以及具體使用了哪些 Vibe Coding 工具。接著，我會講述用戶在使用 Web 編程工具過程中遇到的一些問題。然后，作為 Vibe Coding 工具的兩位核心主導者之一，我會分享我是如何思考這些問題的。最后，我在之前的許多分享中已經(jīng)介紹過我們?nèi)绾问褂脟a(chǎn)模型以及在適配國產(chǎn)模型過程中遇到的問題。

Vibe Coding 產(chǎn)品形態(tài)

目前，Vibe Coding 工具大致可以分為四類。首先是 Native IDE，例如近年來較為流行的 Cursor、Trae，以及我們阿里巴巴的 QCoder 等，它們都以本地集成開發(fā)環(huán)境的形式存在。第二類是 IDE 插件，比如我們內(nèi)部的 Aone Copilot 等工具，這些插件大多是基于現(xiàn)有的開發(fā)環(huán)境，如 VSCode 或 JetBrains 的插件形式存在。目前來看，內(nèi)部用戶使用這類插件仍是一種比較主流的習慣，盡管其靈活性可能不如 Native IDE 那么高。第三類是 Web Agent，它的入口在瀏覽器上，整個執(zhí)行過程在一個異步容器中進行，可能是沙箱環(huán)境。它可以解決信任問題以及云端執(zhí)行中的安全問題，并且對于協(xié)作更加友好，能夠在 Web Agent 中實現(xiàn)多人同步協(xié)作和分享。這類主要是跨平臺工具，具有廣泛的適用性。最后一類是 CLI 命令行工具，這其實是一個比較意外的類別。我們之前并沒有預料到像 Claude Code 這樣的 CLI 工具會如此受歡迎。最初，我們認為這種工具不會受到主流研發(fā)人員的歡迎，但后來發(fā)現(xiàn)大家其實非常接受這種模式。現(xiàn)在我們認為，CLI 模式在被集成的方式中，比如 CI 或一些異步容器中執(zhí)行垂直任務時，具有更高的可用性。這就是我對 Vibe Coding 工具大致分類的介紹。

Vibe Coding 在阿里內(nèi)部的發(fā)展現(xiàn)狀

接下來，我主要介紹一下我主導的兩個 Vibe Coding 工具的使用情況。首先是基于 IDE 的 Vibe Coding 工具。我們內(nèi)部有一個名為 Aone Copilot 的工具，它已經(jīng)存在多年，擁有眾多用戶，每周大約有數(shù)千的活躍用戶。目前，用戶在使用 IDE 的 Vibe Agent 工具時，主要場景包括新增代碼、修復漏洞以及代碼分析等。在后端場景中，這種工具的滲透率相對較高，而在前端場景中，大家可能更傾向于使用 Native IDE，如 Cursor 或 QCoder。

另一個我主導的項目是 Aone Agent。這是一個以外部容器發(fā)起的異步任務工具。它強調(diào)用戶可以通過自然語言發(fā)起任務，我們在異步容器中啟動一個 Agent，這個 Agent 會自行調(diào)用各種工具，無論是搜索工具、文件讀取工具還是 Shell 工具。這種在容器內(nèi)執(zhí)行的異步 Agent 與前面提到的 IDE Agent 有本質(zhì)區(qū)別。雖然用戶主要是后端人員，但我們發(fā)現(xiàn)測試人員、前端人員、算法工程師、產(chǎn)品經(jīng)理、運營人員、設計師以及運維人員等都在使用這種工具。它的用戶群體更加多元，提交的任務類型也更加豐富多樣，包括代碼分析、代碼修改、單元測試、代碼生成以及文案方案調(diào)研等，用戶通過這種工具進行各種探索。

在 Vibe Coding，尤其是 Agent 模式發(fā)展之后，我們看到了一些顯著的變化。以 Aone Copilot 的 Agent 模式為例，從 4 月份開始，我們觀察到用戶提交代碼行數(shù)的變化。藍色的線表示高頻用戶，即那些經(jīng)常使用該工具的用戶。我們發(fā)現(xiàn)，在 Agent 模式下，這些高頻用戶的代碼提交行數(shù)有了顯著提升。雖然整體趨勢都在上升，但高頻用戶的提升更為明顯。從定量角度來看，9 月份高頻用戶每天提交的代碼行數(shù)約為 560 行，而其他用戶只有 400 多行。這至少證明了 Agent 模式在提高效率方面是有效的。

我們還發(fā)現(xiàn)，不同用戶對這些工具的使用方式有所不同。前 10% 的用戶提交的代碼行數(shù)是其他用戶的兩倍。但我認為，Agent 對人的效率提升可能不止兩倍，因為大量的工作可能涉及協(xié)作或會議等。我們還發(fā)現(xiàn)，TOP 10 用戶的 Token 消耗占總消耗的 80%。在 Vibe Coding 工具的使用下，由 AI 生成的代碼提交占比越來越高。隨著 Vibe Coding 工具的發(fā)展，像 JDK 升級、NPM 包升級或 SDK 升級等任務已經(jīng)可以由 AI 完成，尤其是 JDK 11 及以上版本的升級場景，我們內(nèi)部幾乎全部交由 Vibe Coding 工具來完成。此外，數(shù)據(jù)分析和數(shù)據(jù)整理工作也部分交給了 Agent。過去，一些必須由人工完成的任務，如大促過程中的截圖或壓力測試中的重復任務，現(xiàn)在都可以由 Agent 完成。還有一些在研發(fā)過程中成本過高而無法進行的事情，比如一次發(fā)布是否會引發(fā)其他相關系統(tǒng)的故障，現(xiàn)在也在探索使用 Agent 來解決。過去，由于無法審查每一行代碼對其他系統(tǒng)的影響，這類問題很難處理，但如今 Agent 可以承擔這項任務。

用戶在 Vibe Coding 過程中遇到的挑戰(zhàn)

在審視當前技術發(fā)展現(xiàn)狀時，從用戶的角度來看，技術和產(chǎn)品都面臨著一些亟待解決的問題。首先，用戶常常因為 AI 的表現(xiàn)不盡如人意而感到沮喪。從后臺日志中，我們可以看到大量用戶抱怨“電腦太笨了”等類似的不滿情緒，這些反饋充滿了挫敗感。同時，用戶頻繁地刪除和修改代碼的現(xiàn)象也屢見不鮮。無論是公司內(nèi)部還是在社區(qū)中，都存在許多用戶因 Agent 能力不足而陷入困境的情況。此前，甚至有用戶在 GitHub 上分享關于 AI 的“八榮八恥”提示詞，其中不乏諸如“以不修改原始代碼為榮”等觀點。

綜合來看，Vibe Coding 工具給用戶帶來的問題主要體現(xiàn)在以下幾個方面。首先是代碼質(zhì)量問題，生成的代碼往往缺乏質(zhì)量把控。其次是調(diào)試和維護困難，這給用戶帶來了額外的負擔。第三是用戶體驗不佳，目前的 AI 編程工具尚未達到讓用戶滿意的程度。最后是成本與效率問題，這些問題也在一定程度上影響了工具的使用效果。

我認為代碼質(zhì)量不足主要體現(xiàn)在幾個方面。首先是代碼一致性不足。在不同場景下，生成代碼的質(zhì)量和風格存在較大差異。例如，在存量代碼倉庫中編寫代碼時，AI 往往會按照自己的風格生成代碼，這與現(xiàn)有代碼風格不一致。其次，邊界條件的處理不夠完善。對于復雜業(yè)務邏輯的邊界情況，AI 生成的代碼往往處理得不夠充分。此外，生成的代碼還存在性能缺失的問題。最后，安全漏洞問題尤為突出，尤其是 SQL 注入類漏洞。斯坦福大學的一項研究指出，AI 生成的代碼中存在注入類漏洞的比例約為 45%。

在實際應用中，我們發(fā)現(xiàn)了一些典型案例。首先是安全漏洞，包括 SQL 注入和 XSS 攻擊。其次是在邊界邏輯處理方面，邏輯錯誤和邊界條件處理不當?shù)那闆r較為常見，例如空指針異常和數(shù)組越界等問題，這些都是我們在用戶使用過程中觀察到的現(xiàn)象。

我們發(fā)現(xiàn) AI 在代碼生成過程中存在自洽問題。過去，我們曾考慮讓 AI 生成代碼的同時，也生成對應的單元測試，以此來解決代碼質(zhì)量問題。然而，我們很快發(fā)現(xiàn)，如果讓 AI 同時負責代碼邏輯和單元測試的生成，它無法保證質(zhì)量，因為 AI 會在邏輯上進行自洽。例如，下圖展示的一段數(shù)組去重函數(shù)及其對應的測試代碼，雖然測試通過率達到了 100%，但其邏輯實際上是存在問題的。這說明，如果完全依賴 AI 來完成代碼和測試，很容易出現(xiàn)自我擬合的情況。因此，我們建議用戶在使用 AI 生成代碼時，至少有一項由人工進行 Review 或主導，以確保質(zhì)量

在用戶使用 Vibe Coding 工具的過程中，我們還發(fā)現(xiàn)調(diào)試時間增加了 30% 到 50%。這是因為 Vibe Coding 更傾向于生成黑盒代碼邏輯，盡管最終會讓人確認代碼的差異（DIFF）后才能提交，但生成過程和代碼本身通常不會被逐條仔細檢查。因此，我們將其視為一種黑盒操作，AI 生成代碼就像一種“黑魔法”，一旦出現(xiàn)問題，用戶可能不知道從何處入手，技術債務也會不斷累積。

另一個問題是上下文理解的局限性。對于存量任務，其業(yè)務邏輯往往是經(jīng)過多年積累形成的，一些代碼為何如此編寫，是否可以刪除等問題，對于 Agent 來說都是難題。我們認為，Vibe Coding 工具缺乏全局思維，生成的代碼模塊化程度不足，代碼耦合度較高。為了解決這一問題，目前有一些方案，例如 Repo Wiki 或 Deep Wiki 等。

此外，Vibe Coding 缺乏可追溯性，這限制了工具的使用。由于 Vibe Coding 一次性生成大量代碼，我們很難確定是新的需求導致代碼出錯，還是最初生成時就存在錯誤。因此，如何引入版本管理的概念，以便在代碼出錯后能夠回滾到正確狀態(tài)，是一個亟待解決的問題。目前有一些方法，例如在每次修改并通過測試后提交一個 Commit，以便后續(xù)能夠從該 Commit 回滾。也有一些工具，如 Cursor 或其他回滾工具，但總體而言，Vibe Coding 在可追溯性方面仍有不足。用戶在生成大量代碼或經(jīng)過多次迭代后，往往無法進行有效的版本管理，只能選擇回滾或重新開始。

目前 Vibe Coding 工具還無法像人類開發(fā)者那樣熟練運用常見的調(diào)試工具。在過去傳統(tǒng)的編程模式中，開發(fā)者們常常會大量使用調(diào)試工具，例如在代碼中設置斷點，或者在瀏覽器中進行調(diào)試。然而，對于 Vibe Coding 工具來說，要利用這些調(diào)試工具來定位問題的堆棧信息，幾乎是不可能完成的任務。那么，Vibe Coding 工具是如何應對這種情況的呢？它們通常會通過大量打印日志（如 console log）來解決問題。它們要求用戶在執(zhí)行代碼后，將控制臺中的報錯信息或打印內(nèi)容復制并粘貼給工具，以便進一步分析。這種模式不僅需要人工介入，而且效率低下。因此，我認為大型模型的調(diào)試手段相對單一，傳統(tǒng)的調(diào)試方法很難被這些模型有效利用。

從用戶使用 Vibe Coding 工具的角度來看，除了編碼層面的問題外，工具本身也存在諸多不足。首先，穩(wěn)定性和成功率是最大的問題之一。Vibe Coding 工具的執(zhí)行時間往往較長，用戶可能需要等待 30 秒到 5 分鐘才能得到結果，而且并非每次都能成功。失敗的原因可能是模型返回錯誤、工具調(diào)用出錯，或者 IDE 本身不穩(wěn)定等。一些用戶在初次使用后，發(fā)現(xiàn)結果不穩(wěn)定，尤其是在時間緊迫、任務繁重的情況下，他們就不再愿意使用這類工具。

其次，交互界面設計也存在一些問題。這并非缺陷，而是因為許多 Vibe Coding 工具頻繁改版，導致用戶難以找到以前的功能，或者工具中不斷增加新功能，使得用戶感到困惑。以 Devin 為例，它在改版過程中，曾經(jīng)引入了劇本、MCP 市場和知識庫等功能，但后來又取消了。這種頻繁的改版讓用戶難以適應。

第三，溝通和交互存在障礙，主要表現(xiàn)為 AI 的理解能力不足。用戶需要反復確認意圖，尤其是在不同場景下，這種確認雖然有意義，但也增加了溝通成本。例如，在最近流行的 Spark Coding 中，用戶先提出需求，生成設計稿，再讓 Agent 執(zhí)行。對于復雜的任務，這種模式可能是必要的，但對于其他任務，可能需要 Agent 自由探索。此外，長鏈路任務的執(zhí)行能力也存在不足，無法維持長期的上下文對話。由于 Agent 大模型的 Token 有上限，當上下文過長時，其記憶和召回能力就會下降。

最后，工程工作流程的中斷也是一個問題。目前有大量 Vibe Coding 工具，包括 IDE、CLI 和 Web Agent 等，每種工具都有其擅長的領域，但它們無法讓用戶在一個統(tǒng)一的流程或上下文中解決問題。例如，用戶在 IDE 中完成一項任務后，如果切換到 CLI，就需要重新向新的 Agent 介紹需求。這種頻繁切換不僅增加了用戶的負擔，也降低了工作效率。

Vibe Coding 產(chǎn)品自身遇到的挑戰(zhàn)

隨著 Agent 和模型能力的不斷提升，產(chǎn)品功能也在不斷演進。從最初的單代碼補全場景，單個任務 4000 個 Token，到后來的 Chat 模式，單個任務 1000 個 Token，輸出約為 4000 個 Token。再到 IDE 或 CLI 模式，Token 消耗量達到十萬級別。如今，Web Agent 模式具備獨立容器，能夠廣泛使用各種工具，實現(xiàn)多種任務類型的 Agent 模式，Token 消耗量更是達到百萬級別。像 Cursor、Trae 等 Native IDE 工具正在探索 Sub-Agent 或 Multi-Agent 架構，單個任務的 Token 消耗量甚至可能達到上億級別。這種演進模式雖然為用戶提供了更強大的功能，但也給產(chǎn)品設計帶來了挑戰(zhàn)。一方面，我們需要讓用戶滿意，另一方面，成本控制必須與用戶規(guī)模相匹配。

在產(chǎn)品設計方面，Vibe Coding 工具，無論是 IDE Agent 還是 Web Agent，都處于摸索階段。盡管模型能力的提升推動了產(chǎn)品功能的不斷變化，但產(chǎn)品界面的區(qū)分度卻不夠。例如，Chat、Deep Research、Agent 等產(chǎn)品都采用對話框形式，用戶難以區(qū)分不同產(chǎn)品的功能差異。此外，用戶缺乏引導，面對 Vibe Coding 的對話框，用戶往往不知道該輸入什么內(nèi)容。不同工具適用于不同場景，但用戶常常一刀切地認為某個產(chǎn)品應該滿足他們的需求，然而在實際使用中，他們發(fā)現(xiàn)產(chǎn)品無法達到預期目標。這不僅增加了用戶的學習成本，也降低了產(chǎn)品的使用頻次。我們觀察到，像 Devin 這樣的 Web Agent 工具，留存率非常低，這反映出用戶在使用過程中遇到的諸多問題。另一個問題是缺乏一站式的功能閉環(huán)。用戶面臨的不僅僅是代碼編寫問題，還包括發(fā)布、部署、調(diào)試等多方面的問題。目前的 Vibe Coding 工具無法在一個產(chǎn)品中同時解決不同難度問題。比如，初學者可能需要更多指導和簡化功能，而復雜問題則需要更強大的工具支持。這種功能上的割裂導致用戶在使用過程中需要頻繁切換工具，增加了使用成本和學習難度。

Vibe Coding 工具的安全性問題值得我們高度關注?？赡艽蠹矣兴劊?Cursor 曾出現(xiàn)過刪除用戶本地代碼的情況，雖然這類事件相對較少，但今年已經(jīng)發(fā)生了好幾次。另一個案例是 Anthropic 的 Claude Code 被劫持，攻擊者利用 Vibe Coding 工具在用戶網(wǎng)絡中探測漏洞，并編寫代碼將敏感信息暴露出來。

在內(nèi)網(wǎng)環(huán)境中，我們可能還無法完全信任 Vibe Coding 工具。當前，供應鏈攻擊和開源代碼的發(fā)展帶來了新的挑戰(zhàn)。許多人會在開源社區(qū)中潛入木馬，一旦我們稍不留意，拉取的 SDK 或代碼可能本身就存在漏洞。Vibe Coding 工具由于對代碼或當前電腦具有一定的控制能力，能夠進行自由探索，可能會發(fā)現(xiàn)系統(tǒng)中的漏洞并加以利用。因此，我們在使用 Vibe Coding 工具時，必須謹慎對待其安全性問題，確保在安全的環(huán)境中使用，并對工具的權限進行嚴格管理。

Agent 建設過程中的一些經(jīng)驗

在參與 Agent 建設的過程中，我積累了一些經(jīng)驗，這些經(jīng)驗對我們后續(xù)的工作有著重要的啟示。

最初，我們采用了一種 All In One 架構，這種架構在建設 Vibe Agent 時帶來了諸多問題。當時，Vibe Agent 的核心是一個輸入框，圍繞這個輸入框的是 MCP 工具、知識庫（Knowledge）以及各種劇本（Playbook）。這些外圍工具構成了一個完整的場景圖，涵蓋了數(shù)據(jù)處理、后端開發(fā)、前端開發(fā)、代碼審查、風險管理等多個方面。在這種架構下，所有工具和知識都需要放入上下文中，導致上下文內(nèi)容異常龐大，成本難以壓縮。例如，當時我們使用 Claude 模型執(zhí)行一個任務，成本高達幾百元，這顯然是不可持續(xù)的。

此外，這種 All In One 架構還導致任務成功率較低。當所有工具和知識集中在一起時，上下文過長，消耗大量 Token，不僅增加了成本，還降低了任務執(zhí)行的效率。更重要的是，這種架構難以針對不同場景進行優(yōu)化。例如，當我們對比其他類似產(chǎn)品時，我們的 Vibe Agent 在前端場景上的表現(xiàn)卻不盡如人意。這說明，我們的架構缺乏靈活性，無法根據(jù)不同場景進行針對性的調(diào)整和優(yōu)化。

在后續(xù)的 Agent 建設過程中，我們采取了一系列措施來優(yōu)化工具的性能和用戶體驗。首先，我們對知識和數(shù)據(jù)進行了調(diào)整，特別是在代碼數(shù)據(jù)建設方面，通過構建 Repo Wiki 和 Embedding 數(shù)據(jù)庫，提升了對整體代碼庫的搜索理解和搜索能力。此外，我們還將研發(fā)行為數(shù)據(jù)納入考量，包括構建 CI、CR、發(fā)布監(jiān)控等行為。由于我們依托的是集團內(nèi)部的發(fā)布平臺和代碼平臺，因此能夠?qū)⒋a數(shù)據(jù)與需求數(shù)據(jù)相結合，形成一個綜合的數(shù)據(jù)體系。

我們意識到，傳統(tǒng)的文檔知識庫難以直接被 Agent 使用，原因在于這些知識庫可能存在信息過時、前后矛盾、圖文混雜以及錯誤信息等問題。這些問題如果直接傳遞給 Agent，可能會導致誤導。因此，我們沒有采用傳統(tǒng)的 RAG 技術，而是通過建立一個中間層來處理面向 Agent 的數(shù)據(jù)協(xié)議，從而解決文檔知識庫的引入問題。

在 Agent 的建設過程中，我們還發(fā)現(xiàn)很多知識并不在文檔或代碼中，而是存在于開發(fā)者的頭腦中。因此，我們思考如何設計一個產(chǎn)品，幫助用戶將這些知識沉淀下來。這并非通過自動生成實現(xiàn)，而是需要用戶主動參與編寫。

在上下文記憶方面，我們進行了大量處理工作，包括寫入、提取、壓縮和隔離等操作。我們的 Agent 工具旨在滿足大多數(shù)用戶的需求。為此，我們在容器中集成了大量工具，涵蓋任務管理、基本交互、文件操作（讀寫、編輯、管理）、命令行執(zhí)行監(jiān)控等功能。由于 Agent 可以執(zhí)行命令行，對于一些耗時較長的命令，我們需要監(jiān)聽其執(zhí)行結果，并在超時后進行中斷處理。

我們還加入了瀏覽器自動化工具，例如使用 Playwright 等工具進行網(wǎng)頁操作，幫助用戶完成登錄等交互任務。同時，我們還集成了多媒體開發(fā)工具，支持用戶將代碼部署到特定環(huán)境進行調(diào)試。在協(xié)作方面，我們設計了團隊協(xié)作功能，用戶可以將任務分享給他人，基于任務繼續(xù)協(xié)作。我們還加入了高級功能，如并行執(zhí)行優(yōu)化和網(wǎng)絡搜索等

在面對模板和成本過高的問題時，我們采取了一系列措施來優(yōu)化和解決。最初，我們發(fā)現(xiàn)單個任務的 Token 消耗量接近 400 萬到 1000 萬，這是一個極為嚴重的問題。為了降低 Token 成本，我們進行了一些操作和設計調(diào)整。

積極適配和擁抱國產(chǎn)開源模型

在探討為何要解決成本問題時，我相信從事相關工作的人都能理解其重要性。實際上，解決成本問題的另一個重要方向是積極擁抱國產(chǎn)開源模型。然而，國產(chǎn)開源模型并非針對我們的具體場景進行訓練，因此仍存在諸多問題。

使用國外的 SOTA 閉源模型也存在諸多風險。首先，這類模型非常昂貴，尤其是處理復雜問題時，需要在長鏈路任務中運行，成本極高。其次，隱私問題不容忽視，閉源模型可能存在合規(guī)風險。第三，我們還發(fā)現(xiàn)了被限流和性能下降的問題，即使是同一模型、同一供應商，在不同時間的表現(xiàn)也可能不同，有時會出現(xiàn)格式錯誤或陷入死循環(huán)等問題。最后，國外模型在面向 C 端用戶時，可能還存在備案等額外問題。

相比之下，國產(chǎn)模型在短鏈任務中表現(xiàn)良好，但在長鏈任務中仍存在一些問題。例如，死循環(huán)問題較為常見，因為 Agent 有多種選擇和入口，可能在執(zhí)行過程中陷入某種循環(huán)，無法跳出。另一個問題是格式遵循能力不足，例如 XML 標簽格式不準確，前后無法匹配，導致無法正確解析，容易失敗。此外，還存在指令遵循問題，在處理大量 Token 的上下文時，模型可能忘記某些指令，尤其是在未被充分訓練的情況下。最后，我們還發(fā)現(xiàn)全局智能方面存在缺陷，模型容易陷入“走一步看一步”的情況，導致 Token 消耗大，步驟時間長。

為了應對這些問題，我們采取了一系列措施。首先，針對穩(wěn)定性問題，我們設計了主備模型切換和重試機制。其次，為了解決速度慢或 Infra 穩(wěn)定性問題，當模型輸出被截斷時，我們引入了流式輸出和續(xù)寫設計。此外，我們還進行了健康檢查和死循環(huán)檢測，在 Agent 中針對重復執(zhí)行指令或相同錯誤點的無限循環(huán)問題進行了優(yōu)化。當檢測到明顯錯誤邏輯時，我們能夠及時干預。同時，我們還進行了格式檢查和修復，針對模型生成的 XML 標簽格式錯誤，通過堆棧或自動補齊方式解決格式缺失問題。

目前，我們已經(jīng)將所有國外模型替換為國產(chǎn)模型。在運行過程中，我們會實時檢測任務是否進入死循環(huán)，一旦發(fā)現(xiàn)，會采取干預措施，例如截斷后續(xù)任務執(zhí)行，或?qū)θ蝿者M行總結和壓縮，使其能夠繼續(xù)執(zhí)行。這些措施都是我們在上下文管理方面的探索和實踐。

在思考如何提升產(chǎn)品用戶體驗和降低使用成本時，我發(fā)現(xiàn)了一個核心問題：普通用戶甚至小白用戶在使用我們的產(chǎn)品時，往往不清楚產(chǎn)品能做什么。即便他們知道自己需要什么，也難以準確地提出需求，不知道如何在產(chǎn)品中選擇合適的工具或知識。這導致產(chǎn)品的任務成功率很低，同時 Token 消耗量卻很大。

為了解決這些問題，我考慮是否可以將一些已經(jīng)成功完成的垂直任務進行抽象和模板化。例如，如果某個任務經(jīng)過多次探索后成功完成且用戶非常滿意，我們能否將其經(jīng)驗抽象出來，形成一套標準化的模板？通過這種方式，我們可以針對不同的垂直場景不斷積累模板，從而提高任務的成功率，降低 Token 消耗。當用戶面對對話框時，模板也能提供一定的引導性，幫助他們更好地使用產(chǎn)品。

在模板設計方面，這些模板可以被理解為工具組合和知識組合的集合。有了模板后，用戶在使用對話框時可以先選擇一個模板，這大大提高了任務的完成率。目前，大約有 50% 的用戶任務都使用了模板，任務完成率提高到了 95% 以上。通過固化 Prompt、工具和知識，形成模板后，用戶在下次生成或執(zhí)行任務時可以先選擇模板，再進行具體操作。

Manus 1.5 提出了一個新概念：Agent 也是一種工具。這意味著我們可以將 Agent 視為一個工具，例如一個專門用于深度調(diào)研的工具，它可以獨立完成網(wǎng)頁搜索和內(nèi)容總結。這樣，主 Agent 只需要調(diào)用這個工具即可，從而將部分任務抽象化，形成一個工具。從最初的“函數(shù)即工具”，到“LLM 即工具”，再到現(xiàn)在的“Agent 即工具”，我們將所有任務都視為子任務，通過工具化的方式進行處理。

以上內(nèi)容是我關于產(chǎn)品和用戶體驗方面的分享。實際上，我們的工作不僅局限于內(nèi)部，也已經(jīng)向外部用戶開放使用。未來，我們還將進一步把內(nèi)部的技術成果開放給社區(qū)，以促進更廣泛的交流與合作。

演講嘉賓介紹

向邦宇，阿里巴巴代碼平臺負責人，在代碼管理、代碼結構化數(shù)據(jù)處理、代碼搜索、代碼評審以及編輯器技術等領域擁有豐富的專業(yè)知識和實踐經(jīng)驗。在阿里，負責了包括 CloudIDE、代碼搜索、CodeReview 等多個關鍵產(chǎn)品的開發(fā)與管理，成功引領了代碼智能平臺的建設與發(fā)展。他主導實現(xiàn)的阿里內(nèi)部多個 AI Coding 工具，包括 Aone Copilot 和 Aone Agent 等，在阿里內(nèi)部被廣泛使用。他還主導開發(fā)了 AI Development 產(chǎn)品“搭叩”。

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產(chǎn)，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續(xù)的「Value From AI」。從前沿技術雷達、架構設計與數(shù)據(jù)底座、效能與成本、產(chǎn)品與交互、可信落地、研發(fā)組織進化六大維度，系統(tǒng)性展開深度探索。QCon 北京 2026，邀你一起，站在拐點之上。