演講嘉賓｜向邦宇

編輯｜Kitty

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

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

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

內(nèi)容亮點(diǎn)

• Vibe Coding 工具在建設(shè)過(guò)程中遇到的問(wèn)題，以及解決的辦法

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

• 構(gòu)建 Vibe Coding 工具時(shí)的技術(shù)創(chuàng)新與落地實(shí)踐

以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變?cè)獾木庉嬚恚?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agent 建設(shè)過(guò)程中的一些經(jīng)驗(yàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

為了應(yīng)對(duì)這些問(wèn)題，我們采取了一系列措施。首先，針對(duì)穩(wěn)定性問(wèn)題，我們?cè)O(shè)計(jì)了主備模型切換和重試機(jī)制。其次，為了解決速度慢或 Infra 穩(wěn)定性問(wèn)題，當(dāng)模型輸出被截?cái)鄷r(shí)，我們引入了流式輸出和續(xù)寫設(shè)計(jì)。此外，我們還進(jìn)行了健康檢查和死循環(huán)檢測(cè)，在 Agent 中針對(duì)重復(fù)執(zhí)行指令或相同錯(cuò)誤點(diǎn)的無(wú)限循環(huán)問(wèn)題進(jìn)行了優(yōu)化。當(dāng)檢測(cè)到明顯錯(cuò)誤邏輯時(shí)，我們能夠及時(shí)干預(yù)。同時(shí)，我們還進(jìn)行了格式檢查和修復(fù)，針對(duì)模型生成的 XML 標(biāo)簽格式錯(cuò)誤，通過(guò)堆?；蜃詣?dòng)補(bǔ)齊方式解決格式缺失問(wèn)題。

目前，我們已經(jīng)將所有國(guó)外模型替換為國(guó)產(chǎn)模型。在運(yùn)行過(guò)程中，我們會(huì)實(shí)時(shí)檢測(cè)任務(wù)是否進(jìn)入死循環(huán)，一旦發(fā)現(xiàn)，會(huì)采取干預(yù)措施，例如截?cái)嗪罄m(xù)任務(wù)執(zhí)行，或?qū)θ蝿?wù)進(jìn)行總結(jié)和壓縮，使其能夠繼續(xù)執(zhí)行。這些措施都是我們?cè)谏舷挛墓芾矸矫娴奶剿骱蛯?shí)踐。

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

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

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

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

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

演講嘉賓介紹

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

會(huì)議推薦

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

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