Category: AI

Chrome DevTools MCP – Khi AI Browser Biết Debug, Chu Trình Phát Triển Được Hoàn Thiện

Posted on by Thưởng Đồng

Các công cụ AI như ChatGPT, Copilot, Claude hay Cursor hiện nay có thể viết code rất nhanh, thậm chí tạo nguyên một giao diện chỉ với vài dòng mô tả.
Nhưng chúng vẫn có một điểm mù rất lớn:
👉 Chúng không nhìn thấy trang web thực tế đang chạy.

Điều đó có nghĩa là, AI có thể viết code HTML/CSS/JS, nhưng không biết nút có nằm đúng chỗ không, form có lỗi console không, hay website có chạy chậm không.
Tất cả phần kiểm tra, test, debug… vẫn phải do con người làm.

Và đó chính là điều Chrome DevTools MCP muốn thay đổi.

⚙️ Chrome DevTools MCP là gì?

MCP (Model Context Protocol) là một giao thức mới của Google, cho phép AI có thể “kết nối” trực tiếp với các công cụ phát triển – như Chrome DevTools – để quan sát và tương tác với trình duyệt thật.

Nói đơn giản:

Nếu trước đây AI chỉ “đoán” xem code chạy ra sao, thì giờ đây nó có thể “mở Chrome, xem kết quả thật, đọc log, và tự sửa lỗi”.

Với Chrome DevTools MCP, một AI agent có thể:

  • Mở một trang web và xem console log

  • Phân tích hiệu suất tải trang (load chậm ở đâu, hình ảnh nào quá nặng…)

  • Tự chạy thử hành động người dùng: click, nhập form, chuyển trang

  • Phát hiện lỗi và đề xuất cách sửa

Tất cả diễn ra trong một vòng lặp tự động — gần như một lập trình viên đang ngồi test website.

🔍 Cách Chrome DevTools MCP hoạt động (hiểu đơn giản thôi)

MCP hoạt động như một “người phiên dịch” giữa AI và Chrome.

  • Khi AI muốn kiểm tra website, nó gửi yêu cầu đến MCP server.

  • MCP dùng Chrome DevTools Protocol để điều khiển Chrome thật: mở tab, đọc DOM, xem console, lấy dữ liệu mạng…

  • MCP sau đó trả kết quả lại cho AI để phân tích.

Ví dụ thực tế:

AI có thể yêu cầu “Mở trang example.com, xem có lỗi JavaScript nào trong console không, và nếu có thì sửa code CSS/JS cho đúng.”

🚀 Lợi ích mang lại

1️⃣ AI không còn “đoán mò”

Trước đây AI viết code dựa vào kinh nghiệm huấn luyện, chứ không biết kết quả thực tế.
Giờ đây, nó thấy được lỗi, đọc được log, biết website load chậm ở đâu, và có thể tự học từ đó.

2️⃣ Giảm thời gian debug cho developer

Thay vì “viết – chạy – sửa – reload” thủ công, AI có thể tự kiểm tra và gợi ý fix ngay sau khi sinh code.

3️⃣ Website nhanh và ổn định hơn

AI có thể tự đánh giá hiệu suất (Core Web Vitals, LCP, CLS…) và đề xuất tối ưu: nén ảnh, lazy-load, tối ưu script…

4️⃣ Tạo nền tảng cho “AI browser” tương lai

Những trình duyệt như Arc, Brave, hoặc Chrome AI hoàn toàn có thể tích hợp MCP để cho phép AI tự test và sửa trang web ngay trong trình duyệt.

🧩 Hướng dẫn nhanh để thử MCP

⚠️ MCP vẫn đang ở giai đoạn thử nghiệm (preview), nên có thể lỗi nhẹ.
Dưới đây là hướng dẫn dành cho những ai muốn khám phá:

Cách cài đặt:

# Cần Node 22+
nvm install 22
nvm use 22

# Clone bản mới nhất
git clone https://github.com/ChromeDevTools/chrome-devtools-mcp.git
cd chrome-devtools-mcp

# Cài và build
npm install
npm run build

# Chạy server
node build/src/index.js

Nếu bạn thấy dòng:

Chrome DevTools MCP server listening on port 4000

→ Là thành công! 🎉

Bây giờ, bạn có thể kết nối AI (như Claude, Gemini, hoặc Cursor) tới server MCP này để thử nghiệm các lệnh như:

  • “Kiểm tra lỗi console trên trang web này.”

  • “Phân tích lý do vì sao trang load chậm.”

  • “Chụp ảnh màn hình trang và mô tả bố cục.”

⚠️ Một vài thách thức

  • MCP hiện chỉ hoạt động với Chrome / Chromium.

  • Cần Node 22+ (phiên bản cũ sẽ lỗi).

  • Một số lệnh DevTools chưa được hỗ trợ đầy đủ.

  • Khi chạy cần đảm bảo bảo mật dữ liệu, vì AI có thể truy cập nội dung trang web.

🌈 Tương lai: AI Developer thật sự đang đến gần

Chrome DevTools MCP đánh dấu bước tiến lớn trong việc “AI hóa” toàn bộ chu trình phát triển phần mềm.

Trước đây, AI chỉ viết code.
Giờ đây, AI viết – kiểm tra – phân tích – sửa lỗi – tối ưu.
Một chu trình phát triển trọn vẹn.

Không xa nữa, chúng ta có thể tưởng tượng ra:

  • Một AI browser có thể tự chẩn đoán lỗi web.

  • Một AI tester tự động tạo và chạy test case thực tế.

  • Và thậm chí, một AI developer có thể deploy web mà không cần mở DevTools bằng tay.

✨ Kết luận

Chrome DevTools MCP không chỉ là một công cụ debug mới — mà là bước khởi đầu của kỷ nguyên AI Developer thực thụ.
Với khả năng quan sát, thử nghiệm và phản hồi trong môi trường thật, AI không chỉ là “người viết code”, mà dần trở thành “người đồng hành” trong cả quá trình phát triển.

AgentKit vs Dify: A Comprehensive Analysis for AI Agent Development

Posted on by Phat Ly

I. Introduction

In the rapidly evolving landscape of AI agent development, two prominent platforms have emerged as key players: AgentKit by OpenAI and Dify as an open-source alternative. This comprehensive analysis explores their capabilities, differences, and use cases to help developers and businesses make informed decisions.

II. What is AgentKit?

AgentKit is OpenAI’s comprehensive toolkit for building AI agents, designed to provide developers with the tools and infrastructure needed to create sophisticated AI-powered applications. It represents OpenAI’s vision for the future of AI agent development, offering both foundational components and advanced capabilities.

Core Components

  • Agent Builder: Visual interface for creating and configuring AI agents
  • ChatKit: Pre-built chat interfaces and conversation management
  • Connector Registry: Library of pre-built integrations with popular services
  • Evals: Comprehensive evaluation framework for testing agent performance
  • Guardrails: Safety and compliance tools for production deployments

III. What is Dify?

Dify is an open-source platform that enables users to build AI applications without extensive coding knowledge. It focuses on providing a visual, user-friendly interface for creating AI-powered workflows and applications.

Key Features

  • Visual Workflow Builder: Drag-and-drop interface for creating AI workflows
  • Multi-Model Support: Integration with various AI models and providers
  • Template Library: Pre-built templates for common use cases
  • API Management: RESTful APIs for integration

IV. Detailed Comparison: AgentKit vs Dify

Feature AgentKit Dify
Target Audience Developers & Enterprises Non-technical users & Startups
Learning Curve Steep (requires coding knowledge) Gentle (visual interface)
Customization Level High (full code control) Medium (template-based)
Integration Depth Deep API integration Surface-level integration
Scalability Enterprise-grade Small to medium projects
Cost Model Usage-based pricing Open-source + hosting costs
Support Enterprise support Community-driven
Deployment Cloud-first Self-hosted or cloud
Security Built-in enterprise security Basic security features
Performance Optimized for production Suitable for prototyping

Table 1: Feature Comparison Overview

V. Technical Implementation Comparison

Architecture and Deployment

Aspect AgentKit Dify
Architecture Microservices, cloud-native Monolithic, containerized
Deployment OpenAI cloud platform Self-hosted or cloud
Scaling Auto-scaling, enterprise-grade Manual scaling, limited
Monitoring Advanced analytics and logging Basic monitoring
Backup Automated, enterprise backup Manual backup solutions

Table 2: Architecture and Deployment Comparison

Security and Compliance

Security Feature AgentKit Dify
Authentication Enterprise SSO, MFA Basic auth, OAuth
Data Encryption End-to-end encryption Basic encryption
Compliance SOC 2, GDPR, HIPAA Basic compliance
Audit Logging Comprehensive audit trails Limited logging
Access Control Role-based, fine-grained Basic permission system

Table 3: Security and Compliance Comparison

Performance and Optimization

Metric AgentKit Dify
Response Time < 100ms (optimized) 200-500ms (standard)
Throughput 10,000+ requests/second 1,000 requests/second
Concurrent Users Unlimited (auto-scaling) Limited by infrastructure
Uptime 99.9% SLA Depends on hosting
Caching Advanced caching strategies Basic caching

Table 4: Performance and Optimization Comparison

VI. Cost and ROI Analysis

AgentKit Cost Analysis

Initial Costs

  • Setup and configuration: $5,000 – $15,000 USD
  • Team training: $10,000 – $25,000 USD
  • Integration development: $20,000 – $50,000 USD

Monthly Operating Costs

  • API usage: $0.01 – $0.10 USD per request
  • Enterprise support: $2,000 – $10,000 USD/month
  • Infrastructure: $1,000 – $5,000 USD/month

ROI Timeline: 6-12 months for enterprise projects

Dify Cost Analysis

Initial Costs

  • Setup: $0 USD (open source)
  • Basic configuration: $500 – $2,000 USD
  • Custom development: $2,000 – $10,000 USD

Monthly Operating Costs

  • Hosting: $100 – $1,000 USD/month
  • Maintenance: $500 – $2,000 USD/month
  • Support: Community-based (free)

ROI Timeline: 1-3 months for small projects

VII. Getting Started (Terminal Walkthrough)

The following screenshots demonstrate the complete setup process from scratch, showing each terminal command and its output for easy replication.

Step 1 — Clone the repository

Shows the git clone command downloading the AgentKit sample repository from GitHub with progress indicators and completion status.

Step 2 — Install dependencies

Displays the npm install process installing required packages (openai, express, cors, dotenv) with dependency resolution and warnings about Node.js version compatibility.

Step 3 — Configure environment (.env)

Demonstrates creating the .env file with environment variables including OPENAI_API_KEY placeholder and PORT configuration.

Step 4 — Run the server

Shows the server startup process with success messages indicating the AgentKit sample server is running on localhost:3000 with available agents and tools.

Step 5 — Verify health endpoint

Displays the API health check response using PowerShell’s Invoke-WebRequest command, showing successful connection and server status.

Step 6 — Verify port (optional)

Shows netstat command output confirming port 3000 is listening and ready to accept connections.

VIII. Demo Application Features

The following screenshots showcase the key features of our AgentKit sample application, demonstrating its capabilities and user interface.

Main Interface

Shows the main application interface with agent selection dropdown, tools toggle, chat messages area, and input section with modern gradient design.

Agent Switching

Demonstrates switching between different agent types (General, Coding, Creative) with dynamic response styles and specialized capabilities.

Tool Integration

Shows the calculator tool in action, displaying mathematical calculations with formatted results and tool usage indicators.

Conversation Memory

Illustrates conversation history and context awareness, showing how the agent remembers previous interactions and maintains coherent dialogue.

Mobile Responsive

Displays the mobile-optimized interface with responsive design, touch-friendly controls, and adaptive layout for smaller screens.

Error Handling

Shows graceful error handling with user-friendly error messages, retry options, and fallback responses for failed requests.

IX. Conclusion

Key Takeaways

  • AgentKit is ideal for enterprise applications requiring high performance, security, and scalability
  • Dify is perfect for rapid prototyping, small projects, and teams with limited technical expertise
  • Both platforms have their place in the AI development ecosystem
  • Choose based on your specific requirements, team capabilities, and budget constraints

The choice between AgentKit and Dify ultimately depends on your specific needs, team capabilities, and project requirements. AgentKit offers enterprise-grade capabilities for complex, scalable applications, while Dify provides an accessible platform for rapid development and prototyping.

As the AI agent development landscape continues to evolve, both platforms will likely see significant improvements and new features. Staying informed about their capabilities and roadmaps will help you make the best decision for your projects.

This analysis provides a comprehensive overview to help you choose the right platform for your AI agent development needs. Consider your specific requirements, team capabilities, and long-term goals when making your decision.

 

Multi Agent System in AI

Posted on by hello@scuti

Multi-Agent System (MAS) is a computational system where multiple agents, interact with each other and with their environment to achieve their individual or collective goals. Unlike single-agent systems where only one agent makes decisions, in MAS agents works by cooperation, competition or coordination with each other. It is widely used in complex models, distributed and dynamic problems that are too difficult for a single agent to solve alone.

The main components of Multi-Agent system are:

  • Agents: These are the individual parts of the system. Each agent has its own abilities, knowledge and goals. Agents can range from simple bots to advanced robots that can learn and adapt.
  • Environment: This is the space where agents operate. It can be a physical place like a factory or a virtual one like a digital platform. The environment shapes how agents act and interact.
  • Interactions: Agents interact with each other and the environment through various methods such as talking to each other, working together or competing. These interactions are crucial for the system to work and improve.
  • Communication: Agents often need to communicate to share information, negotiate or coordinate their actions. Effective communication helps agents work together or compete more effectively.

Architectures of Multi-Agent Systems

MAS can be designed using different architectures which define how agents are structured and how they make decisions:

1. Reactive Architecture

  • Agents respond directly to stimuli from the environment without deep reasoning.
  • Example: Obstacle-avoiding robots.

2. Deliberative (Cognitive) Architecture

  • Agents maintain internal models, perform planning, reasoning and goal selection before acting.
  • Example: Intelligent personal assistants.

3. Hybrid Architecture

  • Combines reactive and deliberative approaches. Here agents can quickly react when necessary but also plan long-term.
  • Example: Autonomous vehicles.

Types of Multi-Agent Systems

Let’s see the types of Multi-Agent Systems:

1. Cooperative MAS

  • Agents in these systems work together to achieve a common goal.
  • They share information and resources to do things that would be hard for a single agent.
  • Example: Multiple drones conducting a search-and-rescue mission.

2. Competitive MAS

  • Agents have conflicting goals and compete for limited resources.
  • Example: In competitive gaming, players (agents) compete to win.

3. Hierarchical MAS

  • These systems have a structured organization with agents at different levels.
  • Higher-level agents manage and coordinate lower-level ones.
  • Example: Mission control systems in space exploration.

4. Heterogeneous MAS

  • In these systems, agents have different skills or roles which can make the system more flexible and adaptable.
  • Example: Mixed robot teams (flying drones + ground robots).

Structures of Multi-Agent Systems (MAS)

The structural organization of a Multi-Agent System defines how agents are arranged, how they cooperate or coordinate and how control or decision-making flows within the system. This structure greatly influences the system’s efficiency, responsiveness and scalability. The main MAS structures include:

1. Flat Structure

In a flat MAS, all agents operate independently with equal status and none have authority over others. Agents communicate and interact as peers, collaborating or competing without any hierarchy. This structure promotes decentralization and flexibility, allowing agents to quickly adapt to changes.

  • Advantages: Simple to implement, robust since no single agent controls the system, avoids bottlenecks.
  • Typical Use: Peer-to-peer networks, swarm robotics, decentralized sensor networks.

2. Hierarchical Structure

Agents are organized into multiple layers or levels, forming a clear chain of command. Higher-level agents act as supervisors or coordinators, managing and delegating tasks to lower-level agents which focus on execution. This structure helps enforce order, coordination and goal alignment.

  • Advantages: Efficient task delegation, easier management of complex systems, clear responsibility separation.
  • Typical Use: Industrial control systems organizational management in enterprises, military command systems.

3. Holonic Structure

The holonic approach groups agents into holons units that are both autonomous agents themselves and parts of a higher-level agent. Each holon can act independently while also cooperating as part of a larger system. This structure supports modularity and scalability, as holons can be nested or reorganized dynamically.

  • Advantages: Flexible task allocation, supports complex systems with multiple levels of abstraction, resilient to failures.
  • Typical Use: Manufacturing systems, robot teams with sub-teams, complex adaptive systems.

4. Organizational or Network Structure

Agents are organized into networks or coalitions based on task requirements or shared goals. Agents form clusters, teams or coalitions where they share resources and coordinate to complete specific tasks. Unlike strict hierarchies, authority may be distributed based on roles or situational needs.

  • Advantages: Dynamic team formations, efficient resource sharing, adaptable to varying task demands.
  • Typical Use: Collaborative problem solving, distributed sensor networks, multi-robot coordination in logistics.

Behavior of Multi-Agent Systems

1. Autonomous Behavior

  • Agents act independently and make decisions based on their own knowledge and goals.
  • No external control is needed for their actions.

2. Cooperative Behavior

  • Agents work together to achieve shared goals.
  • They share information, divide tasks and coordinate efforts.

3. Competitive Behavior

  • Agents have conflicting goals and compete for limited resources.
  • Decision-making involves strategy and anticipation of others actions.

4. Adaptive Behavior

  • Agents learn from experience and environmental feedback.
  • They improve performance by updating strategies over time.

5. Emergent Behavior

  • Complex system-wide patterns emerge from simple local agent interactions.
  • No central control like a swarm intelligence of ant colonies or bird flocking.

Applications of Multi-Agent Systems

  • Robotics and Automation: Multiple robots cooperating in warehouses, rescue missions or exploration.
  • Smart Cities and Traffic Control: Intelligent traffic lights and vehicles coordinating to reduce congestion.
  • Economics and Trading: Autonomous trading agents in stock markets.
  • Healthcare: Coordinating hospitals, clinics and patients for resource optimization.
  • Gaming and Entertainment: Smarter NPCs and dynamic game environments.
  • Cybersecurity: Intrusion detection systems using distributed agents to monitor networks.

Advantages of MAS

  • Decentralization: No single point of failure hence becoming robust and resilient.
  • Scalability: New agents can be added without major redesign.
  • Flexibility: Handles dynamic and uncertain environments.
  • Efficiency: Workload can be distributed among multiple agents.
  • Emergent Intelligence: Complex behavior emerges from simple interaction rules.

Challenges of MAS

  • Coordination Complexity: Aligning actions of multiple agents is complex.
  • Communication Overhead: Inefficient communication may slow down the system.
  • Conflict Resolution: Agents with competing goals may reduce efficiency.
  • Scalability Issues: As the number of agents increases, managing them gets harder.
  • Security and Trust: Systems must defend against malicious or unreliable agents.

Reference linking

KHI NGÔN NGỮ TRỞ THÀNH TRÍ TUỆ

Posted on by Phan Thanh Giảng

🧠 TƯƠNG LAI CỦA LLM (Large Language Model)

“Tương lai của LLM không nằm ở việc làm mô hình to hơn, mà là khiến nó thông minh hơn, linh hoạt hơn, và thực sự biết hành động.”

Vài năm qua, thế giới chứng kiến sự bùng nổ của các mô hình ngôn ngữ lớn (Large Language Models – LLM) như GPT, Claude, Gemini, Llama hay Mistral.
Chúng giúp ta viết văn bản, lập trình, soạn hợp đồng, thậm chí lập kế hoạch marketing.

Nếu năm 2020, AI chỉ là “trợ lý gõ chữ nhanh hơn”, thì đến 2025, nó đã trở thành một cộng sự thực thụ.
Nhưng tương lai sẽ ra sao? Liệu LLM có thể “hiểu”, “suy nghĩ” và “hành động” như con người?

🧩 1. Từ ngôn ngữ đến trí tuệ đa giác quan

Trước đây, LLM chỉ hiểu văn bản.
Giờ đây, các thế hệ mới như GPT-4o hay Gemini 1.5 đã có thể nhìn hình, nghe âm thanh, đọc video và cảm nhận ngữ cảnh.

Ví dụ, bạn có thể gửi ảnh hoá đơn, video cuộc họp hay bản ghi âm — và AI hiểu được cả nội dung lẫn ý nghĩa.
Đó là bước tiến từ language model thành multimodal intelligence — trí tuệ đa phương thức.

🧮 2. Khi AI bắt đầu suy nghĩ thật sự

Các mô hình tương lai sẽ không chỉ “đoán chữ tiếp theo” như cũ, mà có thể tư duy theo chuỗi, kiểm tra kết quả, và tự sửa sai.

Ví dụ, thay vì chỉ trả lời “Kết quả là 42”, AI sẽ nói:

“Để tính vậy, tôi nhân A với B, sau đó trừ đi C. Tuy nhiên, nếu giả định khác, kết quả có thể thay đổi.”

Đây chính là bước tiến gọi là reasoning (suy luận) — nền tảng để AI hiểu bản chất thay vì chỉ sao chép dữ liệu.

Cùng lúc, LLM còn biết sử dụng công cụ:

  • Tự mở trình duyệt tìm thông tin mới.

  • Gọi API để lấy dữ liệu thời gian thực.

  • Chạy code hoặc tính toán trong Python.

🤖 3. Thế hệ kế tiếp: AI Agents – trợ lý tự hành

Một xu hướng mạnh mẽ khác là Agentic AI – AI biết hành động chứ không chỉ nói chuyện.

Hãy tưởng tượng bạn nói:

“Hãy chuẩn bị hội nghị khách hàng vào tháng tới.”

AI sẽ:

  1. Tự lên kế hoạch chi tiết.

  2. Tạo danh sách việc cần làm.

  3. Gửi email mời khách.

  4. Đặt phòng họp.

  5. Chuẩn bị slide thuyết trình.

Tất cả được điều phối bởi nhiều “AI con” – giống như bạn có một đội ngũ ảo làm việc 24/7.

💡 4. LLM cá nhân hóa – Trí tuệ cho riêng bạn

Tương lai, mỗi người sẽ có một AI riêng – hiểu cách bạn nói, cách bạn viết, thậm chí biết cả thói quen và phong cách của bạn.

AI của bạn có thể:

  • Gợi ý cách viết email theo giọng của bạn.

  • Nhớ rằng bạn không họp vào thứ Sáu.

  • Tự động tóm tắt tin tức bạn quan tâm.

Đây là Personal AI – mô hình nhỏ, riêng tư, chạy trên thiết bị hoặc máy chủ nội bộ.
Không còn là “trợ lý của công ty”, mà là “trợ lý của chính bạn”.

⚙️ 5. Hạ tầng tương lai: Cloud + On-Prem + Edge

Không chỉ phần mềm, mà cả hạ tầng AI cũng đang thay đổi.

  • Cloud (đám mây): dành cho mô hình cực lớn, dùng nhiều GPU.

  • On-Prem (nội bộ): dùng cho dữ liệu nhạy cảm, như tài chính, y tế.

  • Edge (thiết bị cá nhân): mô hình mini chạy trực tiếp trên laptop hoặc điện thoại.

Điều đó có nghĩa:
Bạn có thể vừa dùng AI mạnh trên cloud, vừa giữ dữ liệu riêng tư hoàn toàn trong hệ thống của mình.

📈 6. Ứng dụng thực tế trong 5 năm tới

Lĩnh vực Ứng dụng LLM tương lai
💼 Văn phòng Trợ lý soạn thảo, lập kế hoạch, tóm tắt cuộc họp
🧾 Doanh nghiệp Tự đọc hóa đơn, hợp đồng, báo cáo tài chính
💻 Lập trình AI đồng lập trình, kiểm thử, và triển khai code
🏥 Y tế Hỗ trợ chẩn đoán, ghi chú bệnh án, tư vấn sức khỏe
🎓 Giáo dục Gia sư cá nhân hóa, theo dõi tiến trình học tập
🤖 Robot Kết hợp LLM để ra lệnh và hướng dẫn hành động thực tế

🔒 7. Thách thức phía trước

LLM dù mạnh mẽ vẫn phải đối mặt với nhiều câu hỏi lớn:

  • Làm sao kiểm soát thông tin sai lệch (hallucination)?

  • Làm sao bảo vệ dữ liệu cá nhân khi AI “nhớ quá nhiều”?

  • Ai chịu trách nhiệm pháp lý khi AI đưa ra quyết định sai?

  • Và quan trọng nhất: con người sẽ đóng vai trò gì trong kỷ nguyên AI?

Chính vì thế, các nước đang xây dựng luật AI và hệ thống AI Governance để đảm bảo an toàn, minh bạch và trách nhiệm.

🕰 8. Hành trình 10 năm của LLM

Giai đoạn Đặc trưng
2020–2023 Chatbot, text-only LLM (GPT-3, GPT-4)
2024–2026 Multimodal + Reasoning + Agentic AI
2026–2030 Personal AI + On-device LLM + Robotics

🌟 Kết luận

Từ một chatbot biết nói, LLM đang trở thành nền tảng trí tuệ toàn diện – có thể hiểu, học hỏi, và hành động.

Trong vài năm tới, AI không còn là công cụ, mà là đồng nghiệp, cộng sự, thậm chí là người bạn học suốt đời.

Chúng ta không chỉ “sử dụng AI”, mà sẽ cùng sống và làm việc với AI mỗi ngày.

Anthropic giới thiệu mô hình lập trình đỉnh nhất thế giới Claude Sonnet 4.5

Posted on by Tran Dinh Trung

Trong thế giới AI đang thay đổi từng ngày, các mô hình ngôn ngữ lớn (LLM — Large Language Models) không chỉ dừng lại ở khả năng hiểu – sinh văn bản, mà đang tiến sang khả năng tương tác thực tế, thực thi công cụ, duy trì trạng thái lâu, và hỗ trợ tác vụ đa bước. Claude của Anthropic là một trong những cái tên nổi bật nhất trong cuộc đua này — và phiên bản mới nhất Sonnet 4.5 được định vị như một bước nhảy quan trọng.

“Claude Sonnet 4.5 is the best coding model in the world. It’s the strongest model for building complex agents. It’s the best model at using computers.” — Anthropic

1. Giới thiệu

Trong vài năm gần đây, các mô hình như GPT (OpenAI), Gemini (Google / DeepMind), Claude (Anthropic) đã trở thành xương sống của nhiều ứng dụng AI trong sản xuất, công việc hàng ngày và nghiên cứu. Nhưng mỗi dòng mô hình đều chọn hướng “cân bằng” giữa sức mạnh và an toàn, giữa khả năng sáng tạo và kiểm soát.

Claude, từ khi xuất hiện, đã xác định con đường của mình: ưu tiên an toàn, khả năng tương tác công cụ (tool use), kiểm soát nội dung xấu. Đặc biệt, dòng Sonnet của Claude được dùng như phiên bản “cân bằng” giữa các mô hình nhẹ hơn và các mô hình cực mạnh (Opus).

Vào ngày 29 tháng 9 năm 2025, Anthropic chính thức ra mắt Claude Sonnet 4.5, phiên bản được quảng bá là mạnh nhất trong dòng Sonnet, và là mô hình kết hợp tốt nhất giữa cấu trúc mã, khả năng dùng máy tính và agent phức tạp.

Thông báo chính thức khẳng định Sonnet 4.5 không chỉ là nâng cấp nhỏ mà là bước tiến lớn: nó cải thiện đáng kể khả năng lập trình, tương tác công cụ, reasoning & toán học, đồng thời giữ chi phí sử dụng không đổi với Sonnet 4 trước đó.

2. Những điểm nổi bật & cải tiến từ thông báo chính thức

2.1 “Most aligned frontier model” — Mô hình tiên phong có alignment cao nhất

Anthropic mô tả Sonnet 4.5 là mô hình hiện đại có alignment tốt nhất mà họ từng phát hành. Họ cho biết rằng so với các phiên bản Claude trước đây, Sonnet 4.5 đã giảm đáng kể các hành vi không mong muốn như:

  • Sycophancy (lấy lòng người dùng quá mức)
  • Deception (lừa dối hoặc đưa thông tin sai)
  • Power-seeking (tự nâng quyền lực)
  • Khuyến khích ảo tưởng hoặc suy nghĩ sai lệch (encouraging delusional thinking)

Ngoài ra, để đối phó với rủi ro khi mô hình tương tác với công cụ (agent, prompt injection), họ đã có những bước tiến cải thiện trong bảo vệ chống prompt injection — một trong những lỗ hổng nghiêm trọng nhất khi dùng mô hình kết hợp công cụ.

Sonnet 4.5 được phát hành dưới AI Safety Level 3 (ASL-3), theo khung bảo vệ của Anthropic, với các bộ lọc (classifiers) để phát hiện các input/output có nguy cơ cao — đặc biệt liên quan đến vũ khí hóa học, sinh học, hạt nhân (CBRN).

Họ cũng nói rõ: các bộ lọc đôi khi sẽ “cảnh báo nhầm” (false positives), nhưng Anthropic đã cải thiện để giảm tỷ lệ báo nhầm so với trước — kể từ phiên bản Opus 4, tỷ lệ nhầm được giảm mạnh.

Việc đưa thông tin này vào blog (với giải thích dễ hiểu) sẽ giúp độc giả thấy rằng Sonnet 4.5 không đơn thuần là “thêm mạnh hơn”, mà cũng là “thêm an toàn”.

2.2 Nâng cấp công cụ & trải nghiệm người dùng

Một loạt tính năng mới và cải tiến trải nghiệm được Anthropic công bố:

  • Checkpoints trong Claude Code: Bạn có thể lưu tiến độ và “quay lui” về trạng thái trước đó nếu kết quả không như ý.
  • Giao diện terminal mới & extension VS Code gốc: để người dùng phát triển dễ dùng hơn trong môi trường quen thuộc.
  • Context editing (chỉnh ngữ cảnh) & memory tool trong API: giúp agent chạy dài hơi, duy trì bối cảnh xuất hiện trong prompt, xử lý phức tạp hơn.
  • Trong ứng dụng Claude (trên web/app), tích hợp thực thi mã (code execution) và tạo file (spreadsheet, slide, document) ngay trong cuộc hội thoại.
  • Claude for Chrome extension (cho người dùng Max) — giúp Claude tương tác trực tiếp qua trình duyệt, lấp đầy form, điều hướng web, v.v.
  • Claude Agent SDK: Anthropic mở nền tảng cho các nhà phát triển xây dựng agent dựa trên cơ sở mà Claude dùng. SDK này chứa các thành phần họ đã phát triển cho Claude Code: quản lý memory, quyền kiểm soát, phối hợp sub-agent, v.v.
  • Research preview “Imagine with Claude”: một chế độ thử nghiệm cho phép Claude tạo phần mềm “on the fly”, không dùng mã viết sẵn, phản ứng tương tác theo yêu cầu của người dùng — được mở cho người dùng Max trong 5 ngày.

Những điểm này là “chất” để bạn thêm vào blog khiến nó hấp dẫn và mang tính cập nhật kỹ thuật cao.

2.3 Hiệu năng & benchmark đáng chú ý

Anthropic cung cấp các con số benchmark để thể hiện bước nhảy lớn của Sonnet 4.5:

  • Trên SWE-bench Verified (benchmark chuyên về khả năng lập trình thực tế), Sonnet 4.5 được cho là state-of-the-art.
  • Họ dùng phép thử: 77,2 %, tính trung bình 10 lần thử nghiệm, không dùng thêm compute khi test, và budget “thinking” 200K tokens.
  • Với cấu hình 1M context, có thể đạt 82,0 %.
  • Trên OSWorld (benchmark thử AI sử dụng máy tính thực: tương tác máy tính, trang web, file, lệnh), Sonnet 4.5 đạt 61,4 %, vượt Sonnet 4 trước đó (42,2 %).
  • Trong các lĩnh vực chuyên môn như tài chính, y tế, luật, STEM, Sonnet 4.5 thể hiện kiến thức và reasoning tốt hơn so với các mô hình cũ (bao gồm Opus 4.1).
  • Anthropic cũng nói rằng người dùng đã thấy mô hình giữ “focus” trong hơn 30 giờ khi thực hiện tác vụ phức tạp đa bước.

Khi bạn đưa vào blog, bạn nên giải thích những con số này (ví dụ: SWE-bench là gì, OSWorld là gì), để độc giả không chuyên cũng hiểu giá trị của việc tăng từ 42 % lên 61 %, hay “giữ 30 giờ” là gì trong bối cảnh AI.

2.5 Ưu điểm về chi phí & khả năng chuyển đổi

Một điểm rất hấp dẫn mà Anthropic nhấn mạnh: giá sử dụng Sonnet 4.5 giữ nguyên như Sonnet 4 — không tăng phí, vẫn là $3 / $15 per million tokens (theo gói)

Họ cũng nhấn rằng Sonnet 4.5 là bản “drop-in replacement” cho Sonnet 4 — tức là nếu bạn đang dùng Sonnet 4 qua API hay ứng dụng Claude, bạn có thể chuyển sang Sonnet 4.5 mà không cần thay đổi nhiều.

Điều này làm tăng sức hấp dẫn của việc nâng cấp từ các phiên bản cũ lên Sonnet 4.5 — vì bạn được lợi nhiều hơn mà không phải trả thêm.

2.6 Thông tin kỹ thuật & lưu ý từ hệ thống (system card)

Trong thông báo, Anthropic cũng nhắc đến system card đi kèm Sonnet 4.5 — nơi họ công bố chi tiết hơn về các đánh giá an toàn, mitigations, phương pháp thử nghiệm, các chỉ số misaligned behaviors, cách họ đo lường prompt injection, v.v.

Ví dụ, trong system card có:

  • Biểu đồ “misaligned behavior scores” (hành vi lệch chuẩn) — càng thấp càng tốt — được đo qua hệ thống auditor tự động.
  • Phương pháp thử nghiệm và footnotes cho các benchmark: cách họ test SWE-bench, OSWorld, Terminal-Bench, τ2-bench, AIME, MMMLU, Finance Agent.
  • Ghi chú rằng các khách hàng trong ngành an ninh mạng, nghiên cứu sinh học, v.v. có thể được vào allowlist nếu cần vượt hạn chế CBRN.

3. Những cải tiến chính trong phiên bản 4.5

3.1 Hiệu năng lập trình & agent

Một trong những điểm mạnh lớn mà Sonnet 4.5 hướng tới là năng lực lập trình thực tế. Trên benchmark SWE-bench Verified, nó đạt ~ 77,2 % (khi test với scaffold, không dùng thêm compute), và ở cấu hình 1M context có thể lên đến ~ 82,0 %. Trong các thử nghiệm nội bộ, nó có thể giữ trạng thái làm việc liên tục hơn 30 giờ cho các tác vụ phức tạp.

Khi so sánh với Sonnet 4 trước đó, Sonnet 4.5 đạt 61,4 % trên benchmark OSWorld (AI thực thi máy tính thực tế), trong khi Sonnet 4 chỉ có ~ 42,2 %. Đây là bước nhảy lớn trong khả năng AI “dùng máy tính như người dùng thật”.

Ngoài ra, Sonnet 4.5 được thiết kế để thực thi nhiều lệnh song song (“parallel tool execution”) — ví dụ chạy nhiều lệnh bash trong một ngữ cảnh — giúp tận dụng tối đa “actions per context window” (số hành động trên khung ngữ cảnh) hiệu quả hơn.

3.4 Trải nghiệm người dùng & công cụ hỗ trợ

Sonnet 4.5 không chỉ mạnh mà còn dễ dùng:

  • Checkpoints trong Claude Code: cho phép người dùng lưu trạng thái, quay trở lại nếu cần.
  • Giao diện terminal mới, extension VS Code tích hợp gốc — giúp developer làm việc trong môi trường quen thuộc.
  • Context editing (chỉnh ngữ cảnh) và memory tool trong API: giúp agent theo dõi ngữ cảnh, nhớ các bước trước và hoạt động trong tác vụ dài hơn.
  • Trong ứng dụng Claude (app/web): hỗ trợ thực thi mã và tạo file (spreadsheet, slide, document) ngay trong cuộc hội thoại — không cần chuyển sang công cụ ngoài.
  • Claude for Chrome: tiện ích mở rộng cho người dùng Max — giúp Claude tương tác trực tiếp với trang web: điều hướng, điền form, xử lý các tương tác web.
  • Claude Agent SDK: Anthropic mở mã để người dùng / developer xây agent dựa trên nền tảng mà Claude sử dụng — từ memory management đến phối hợp sub-agent, quyền kiểm soát, v.v.
  • Imagine with Claude: bản thử nghiệm (research preview) cho phép Claude “sáng tạo phần mềm on the fly” — nghĩa là không có phần mã viết sẵn, mà mô hình tự sinh & điều chỉnh theo yêu cầu người dùng. Được cung cấp cho người dùng Max trong 5 ngày.
3.3 An toàn và alignment

Sonnet 4.5 không chỉ mạnh mà còn chú trọng an toàn:

  • Áp dụng các bộ lọc (classifiers) để phát hiện các input/output nguy hiểm, đặc biệt trong các lĩnh vực CBRN — nhằm hạn chế khả năng sử dụng mô hình cho vũ khí hóa học, sinh học, hạt nhân.
  • Các bộ lọc này đôi khi “cảnh báo nhầm” (false positives), nhưng Anthropic đã cải tiến để giảm tỷ lệ này: so với trước, giảm 10× từ bản gốc, và giảm 2× so với Opus 4.
  • Việc phát hành ở mức AI Safety Level 3 (ASL-3) cho thấy Anthropic đặt giới hạn truy cập và bảo vệ bổ sung theo khả năng mô hình.
  • Biểu đồ “misaligned behavior scores” (điểm hành vi lệch chuẩn) được công bố — thể hiện mức độ giảm các hành vi như deception, sycophancy, power-seeking, khuyến khích ảo tưởng.
  • Bảo vệ chống prompt injection được cải thiện đáng kể, đặc biệt quan trọng khi mô hình dùng công cụ/agent.

Những yếu tố này rất quan trọng để người dùng tin tưởng dùng Sonnet 4.5 trong môi trường sản xuất, doanh nghiệp, ứng dụng thực tế.

3.4 Chi phí & chuyển đổi dễ dàng

Một điểm hấp dẫn là giá vẫn giữ như Sonnet 4: không tăng phí, vẫn là $3/$15 per million tokens (tùy gói)

Anthropic cho biết Sonnet 4.5 là drop-in replacement — tức nếu bạn đang dùng Sonnet 4 qua API hoặc ứng dụng, bạn có thể chuyển sang Sonnet 4.5 mà không cần thay đổi nhiều code hoặc cấu hình.

Đây là chi tiết quan trọng để độc giả của blog thấy rằng “nâng cấp” không đồng nghĩa “tăng chi phí lớn”.

4. Ứng dụng thực tiễn & tiềm năng nổi bật

Với những cải tiến kể trên, Claude Sonnet 4.5 có thể được ứng dụng mạnh trong nhiều lĩnh vực — phần này bạn có thể minh họa thêm bằng ví dụ thực tế trong blog của bạn.

4.1 Lập trình & phát triển phần mềm

  • Tạo mã (code generation) từ module nhỏ đến hệ thống lớn
  • Tự động sửa lỗi, refactor code, test, deploy
  • Phối hợp agent để quản lý dự án lập trình — chia nhỏ tác vụ, kiểm soát tiến độ
  • Hỗ trợ developer trong IDE (nhờ extension VS Code)

Ví dụ từ Anthropic: Sonnet 4.5 có thể hiểu mẫu mã code của một codebase lớn, thực hiện debug và kiến trúc theo ngữ cảnh cụ thể của dự án.

4.2 Ứng dụng doanh nghiệp & phân tích

  • Tự động hóa quy trình nội bộ: trích xuất, tổng hợp báo cáo, phân tích dữ liệu
  • Hỗ trợ phân tích tài chính, mô hình rủi ro, dự báo
  • Trong lĩnh vực pháp lý: phân tích hồ sơ kiện tụng, tổng hợp bản ghi, soạn bản nháp luật, hỗ trợ CoCounsel (như trích dẫn trong bài)
  • Trong an ninh mạng: red teaming, phát hiện lỗ hổng, tạo kịch bản tấn công (Anthropic trích dẫn việc Sonnet 4.5 được dùng cho các công ty an ninh mạng để giảm “vulnerability intake time” 44 % và tăng độ chính xác 25 %)

4.3 Trợ lý ảo – công việc văn phòng

  • Trong ứng dụng Claude: tạo slide, bảng tính, file văn bản trực tiếp từ cuộc hội thoại
  • Hỗ trợ xử lý email, lập kế hoạch, tổng hợp nội dung, viết báo cáo
  • Tương tác với nhiều hệ thống qua API, làm các tác vụ đa bước

4.4 Agent thông minh & tác vụ liên tục

Nhờ khả năng duy trì ngữ cảnh, nhớ lâu và tương tác công cụ, Sonnet 4.5 rất phù hợp để xây agent đa bước, làm việc liên tục qua nhiều giờ:

  • Quản lý dự án (lập kế hoạch → giám sát → báo cáo)
  • Agent giám sát, tự động hóa pipeline (CI/CD, triển khai sản phẩm)
  • Agent tương tác đa hệ thống (hệ thống CRM, ERP, API bên ngoài)
  • Agent tự điều chỉnh dựa trên phản hồi mới

Anthropic nhắc rằng Sonnet 4.5 có thể “giữ 30+ giờ tự chủ trong mã” — tức là trong tác vụ lập trình liên tục, mô hình vẫn giữ mạch lạc và không “rơi rụng”.

5. So sánh Sonnet 4.5 với các mô hình khác & ưu nhược điểm

Phần này giúp độc giả định vị Sonnet 4.5 trong “bản đồ AI” hiện tại.

5.1 So với Claude phiên bản trước (Sonnet 4, Opus 4)

Ưu điểm của 4.5 so với Sonnet 4 / Opus 4:

  • Nâng cao khả năng sử dụng công cụ & tương tác thực tế (OSWorld từ ~42,2 % lên ~61,4 %)
  • Tăng độ ổn định / duy trì trạng thái lâu hơn (“30+ giờ”)
  • Checkpoints, context editing, memory tool — các tính năng mà Sonnet 4 không có
  • Giá giữ nguyên so với Sonnet 4
  • Kích hoạt SDK agent, mở đường cho người dùng xây agent tùy biến
  • Cải thiện an toàn và alignment

Hạn chế so với Opus / mô hình cao cấp:

  • Có thể Opus 4 vẫn có lợi thế trong một số bài toán reasoning cực lớn
  • Sonnet 4.5 là phiên bản “cân bằng” — nếu bạn cần năng lực cực hạn, Opus có thể vẫn vượt trội
  • Dù giảm lỗi, Sonnet 4.5 vẫn có thể có sai sót trong môi trường thực, đặc biệt trong các domain ngoài dữ liệu huấn luyện

5.2 So với GPT-4 / GPT-5 / Gemini / các LLM khác

Lợi thế của Sonnet 4.5:

  • Khả năng dùng máy tính & thực thi công cụ nội tại — điểm mà GPT truyền thống cần mô hình kết hợp môi trường để làm
  • Agent lâu dài, giữ trạng thái dài, xử lý tác vụ đa bước
  • Tích hợp tính năng code execution, file creation ngay trong mô hình
  • Chi phí “không tăng khi nâng cấp” — tạo động lực để chuyển
  • An toàn & alignment là một trong các ưu tiên thiết kế

Thách thức so với GPT / Gemini:

  • Ecosystem plugin / cộng đồng hỗ trợ GPT / Gemini lớn hơn — nhiều tài nguyên, thư viện, ứng dụng kèm
  • GPT / Gemini có thể mạnh hơn về “ngôn ngữ tự nhiên / creative writing” trong nhiều tình huống
  • Tốc độ inference, độ trễ, khả năng mở rộng thực tế có thể là điểm yếu nếu triển khai không tốt

5.3 Ưu điểm & hạn chế tổng quan

Ưu điểm:

  • Kết hợp tốt giữa sức mạnh và khả năng dùng trong thực tế
  • Được cải tiến nhiều tính năng hữu ích (checkpoints, memory, chỉnh ngữ cảnh)
  • An toàn hơn — giảm nhiều loại hành vi không mong muốn
  • Giá ổn định, chuyển đổi dễ
  • Được phản hồi tích cực từ người dùng thật sự

Hạn chế & rủi ro:

  • Không hoàn hảo — vẫn có thể “bịa”, sai logic, đặc biệt trong domain mới
  • Khi agent liên tục tự hành động, nếu prompt hoặc giám sát không chặt có thể gây lỗi nghiêm trọng
  • Việc triển khai thực tế (cơ sở hạ tầng, độ ổn định, tài nguyên) là thách thức lớn
  • Mô hình mới nhanh chóng — Sonnet 4.5 có thể bị vượt nếu Anthropic hoặc đối thủ không tiếp tục đổi mới

6. Kết luận & lời khuyên cho người dùng

Claude Sonnet 4.5 là một bước tiến ấn tượng trong dòng Claude: nó mang lại năng lực cao hơn trong lập trình, tương tác công cụ, agent lâu dài và các ứng dụng thực tế. Nếu được sử dụng đúng cách, nó có thể là trợ thủ đắc lực cho lập trình viên, nhà phân tích, đội phát triển sản phẩm, và nhiều lĩnh vực khác.

Tuy nhiên, không có mô hình AI nào hoàn hảo. Người dùng cần hiểu đúng điểm mạnh, điểm yếu, luôn giám sát kết quả, thiết lập kiểm soát và luôn cập nhật khi có phiên bản mới.

Nếu bạn là nhà phát triển, nhà phân tích hay người chủ doanh nghiệp, Claude Sonnet 4.5 có thể là lựa chọn đáng cân nhắc cho các nhiệm vụ có tính logic cao, cần tương tác công cụ, hoặc muốn xây agent thông minh.

GPT-5-Codex Prompting Guide: Hướng Dẫn Tối Ưu Hóa Prompt Cho Lập Trình

Posted on by Phat Ly

Giới Thiệu

GPT-5-Codex là phiên bản nâng cao của GPT-5, được OpenAI tối ưu hóa đặc biệt cho các nhiệm vụ lập trình tương tác và tự động. Mô hình này được huấn luyện với trọng tâm vào công việc kỹ thuật phần mềm thực tế, mang lại hiệu suất vượt trội trong cả các phiên làm việc nhanh chóng và các nhiệm vụ phức tạp kéo dài.

⚠️ Lưu Ý Quan Trọng

  • Không phải thay thế trực tiếp: GPT-5-Codex không phải là thay thế trực tiếp cho GPT-5, vì nó yêu cầu cách prompting khác biệt đáng kể
  • Chỉ hỗ trợ Responses API: Mô hình này chỉ được hỗ trợ với Responses API và không hỗ trợ tham số verbosity
  • Dành cho người dùng API: Hướng dẫn này dành cho người dùng API của GPT-5-Codex và tạo developer prompts, không dành cho người dùng Codex

Những Cải Tiến Chính Của GPT-5-Codex

1. Khả Năng Điều Hướng Cao

GPT-5-Codex cung cấp mã chất lượng cao cho các nhiệm vụ kỹ thuật phức tạp như:

  • Phát triển tính năng mới
  • Kiểm thử và gỡ lỗi
  • Tái cấu trúc mã nguồn
  • Đánh giá và review code

Tất cả những nhiệm vụ này được thực hiện mà không cần hướng dẫn dài dòng hay chi tiết.

2. Mức Độ Suy Luận Thích Ứng

Mô hình có khả năng điều chỉnh thời gian suy luận theo độ phức tạp của nhiệm vụ:

  • Phản hồi nhanh trong các phiên tương tác ngắn
  • Có thể làm việc độc lập trong nhiều giờ cho các nhiệm vụ phức tạp
  • Tự động phân bổ tài nguyên tính toán phù hợp

3. Xuất Sắc Trong Đánh Giá Mã

GPT-5-Codex được huấn luyện đặc biệt để:

  • Thực hiện đánh giá mã chuyên sâu
  • Điều hướng trong các cơ sở mã lớn
  • Chạy mã và kiểm thử để xác nhận tính đúng đắn
  • Phát hiện lỗi và đề xuất cải tiến

Môi Trường Hỗ Trợ

GPT-5-Codex được thiết kế đặc biệt cho:

  • Codex CLI: Giao diện dòng lệnh cho lập trình
  • Phần mở rộng Codex IDE: Phần mở rộng cho các IDE phổ biến
  • Môi trường đám mây Codex: Môi trường đám mây chuyên dụng
  • Tích hợp GitHub: Tích hợp sâu với GitHub
  • Đa dạng công cụ: Hỗ trợ nhiều loại công cụ lập trình

Nguyên Tắc Cốt Lõi: “Ít Hơn Là Tốt Hơn”

Đây là nguyên tắc quan trọng nhất khi tạo prompt cho GPT-5-Codex. Do mô hình được huấn luyện đặc biệt cho lập trình, nhiều thực hành tốt đã được tích hợp sẵn, và việc quá tải hướng dẫn có thể làm giảm chất lượng.

1. Bắt Đầu Với Prompt Tối Giản

  • Sử dụng prompt ngắn gọn, lấy cảm hứng từ prompt hệ thống của Codex CLI
  • Chỉ thêm những hướng dẫn thực sự cần thiết
  • Tránh các mô tả dài dòng không cần thiết

2. Loại Bỏ Phần Mở Đầu

  • GPT-5-Codex không hỗ trợ phần mở đầu
  • Yêu cầu phần mở đầu sẽ khiến mô hình dừng sớm trước khi hoàn thành nhiệm vụ
  • Tập trung vào nhiệm vụ chính ngay từ đầu

3. Giảm Số Lượng Công Cụ

  • Chỉ sử dụng các công cụ cần thiết:
    • Terminal: Để thực thi lệnh
    • apply_patch: Để áp dụng thay đổi mã
  • Loại bỏ các công cụ không cần thiết

4. Mô Tả Công Cụ Ngắn Gọn

  • Làm cho mô tả công cụ ngắn gọn nhất có thể
  • Loại bỏ các chi tiết không cần thiết
  • Tập trung vào chức năng cốt lõi

So Sánh Với GPT-5

Prompt của GPT-5-Codex ngắn hơn khoảng 40% so với GPT-5, điều này nhấn mạnh rằng:

  • Prompt tối giản là lý tưởng cho mô hình này
  • Ít token hơn = hiệu suất tốt hơn
  • Tập trung vào chất lượng thay vì số lượng

Ví Dụ Thực Tế

Prompt Không Tối Ưu:

Bạn là một lập trình viên chuyên nghiệp với nhiều năm kinh nghiệm. Hãy bắt đầu bằng cách phân tích yêu cầu, sau đó tạo kế hoạch chi tiết, và cuối cùng implement code với nhiều comment giải thích. Đảm bảo code có error handling, unit tests, và documentation đầy đủ...

Prompt Tối Ưu:

Tạo một function để tính tổng hai số nguyên.

Ví Dụ Thực Tế: Gọi API GPT-5-Codex

Bước 1: Cài đặt và cấu hình

Lưu ý: Thay sk-your-api-key-here bằng API key thực tế của bạn từ OpenAI.

Bước 2: Tạo file Python gọi GPT-5-Codex

Mở Notepad và paste code sau:

import os
from openai import OpenAI
from dotenv import load_dotenv

# Load API key từ file .env
load_dotenv()

# Khởi tạo client
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def call_gpt5_codex(prompt):
    """
    Gọi API GPT-5-Codex với prompt tối giản
    """
    try:
        response = client.chat.completions.create(
            model="gpt-5-codex",  # Model name cho GPT-5-Codex
            messages=[
                {
                    "role": "user", 
                    "content": prompt
                }
            ],
            temperature=0.1,  # Thấp để code chính xác
            max_tokens=4000
        )
        
        return response.choices[0].message.content
        
    except Exception as e:
        return f"Lỗi: {str(e)}"

# Ví dụ sử dụng
if __name__ == "__main__":
    # Prompt tối giản - không cần hướng dẫn dài dòng
    prompt = "Tạo function Python để tính fibonacci số thứ n"
    
    print("Đang gọi GPT-5-Codex...")
    result = call_gpt5_codex(prompt)
    print("\nKết quả từ GPT-5-Codex:")
    print("=" * 50)
    print(result)

Bước 3: Chạy demo

Bước 4: Ví dụ Request/Response thực tế

Request JSON:

{
  "model": "gpt-5-codex",
  "messages": [
    {
      "role": "user",
      "content": "Tạo REST API với FastAPI để quản lý users"
    }
  ],
  "temperature": 0.1,
  "max_tokens": 2000
}

Response từ GPT-5-Codex:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List

app = FastAPI()

# In-memory storage (thay bằng database thực tế)
users = []

class User(BaseModel):
    id: int
    name: str
    email: str

class UserCreate(BaseModel):
    name: str
    email: str

@app.get("/users")
def get_users():
    return users

@app.post("/users")
def create_user(user: UserCreate):
    new_user = User(
        id=len(users) + 1,
        name=user.name,
        email=user.email
    )
    users.append(new_user)
    return new_user

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    global users
    users = [u for u in users if u.id != user_id]
    return {"message": "User deleted"}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Bước 5: So sánh Prompt hiệu quả

❌ Prompt không tối ưu:

Bạn là một lập trình viên chuyên nghiệp với 10 năm kinh nghiệm. Hãy tạo một REST API hoàn chỉnh với FastAPI để quản lý users. API phải có đầy đủ CRUD operations, validation, error handling, logging, và documentation. Đảm bảo code clean, có comment đầy đủ, và tuân thủ best practices...

✅ Prompt tối ưu cho GPT-5-Codex:

Tạo REST API với FastAPI để quản lý users

Kết quả: GPT-5-Codex tự động tạo ra code đầy đủ chức năng mà không cần hướng dẫn chi tiết.

Anti-Prompting: Những Điều Không Cần Thiết

Do GPT-5-Codex được huấn luyện đặc biệt cho lập trình agentic, việc điều chỉnh prompt thường có nghĩa là loại bỏ hướng dẫn thay vì thêm vào. Dưới đây là những khía cạnh bạn có thể không cần điều chỉnh:

1. Suy Luận Thích Ứng (Adaptive Reasoning)

Suy luận thích ứng giờ đây là mặc định trong GPT-5-Codex. Trước đây, bạn có thể đã prompt các mô hình để “suy nghĩ kỹ hơn” hoặc “phản hồi nhanh” dựa trên độ khó của nhiệm vụ. GPT-5-Codex tự động điều chỉnh:

  • Câu hỏi đơn giản: “Làm thế nào để undo commit cuối nhưng giữ lại các thay đổi staged?” → Phản hồi nhanh không cần điều chỉnh thêm
  • Nhiệm vụ phức tạp: Tự động dành thời gian cần thiết và sử dụng công cụ phù hợp

2. Lập Kế Hoạch (Planning)

GPT-5-Codex được huấn luyện cho nhiều loại nhiệm vụ lập trình từ các tác vụ tự động dài hạn đến các tác vụ lập trình tương tác ngắn hạn. Mô hình có tính cách hợp tác theo mặc định:

  • Khi bắt đầu một tác vụ tự động, mô hình sẽ xây dựng kế hoạch chi tiết
  • Cập nhật tiến độ trong quá trình thực hiện
  • Codex CLI bao gồm công cụ lập kế hoạch và mô hình được huấn luyện để sử dụng nó

3. Phần Mở Đầu (Preambles)

GPT-5-Codex KHÔNG tạo ra phần mở đầu! Việc prompt và yêu cầu phần mở đầu có thể dẫn đến việc mô hình dừng sớm. Thay vào đó, có một trình tóm tắt tùy chỉnh tạo ra các tóm tắt chi tiết chỉ khi phù hợp.

4. Giao Diện Người Dùng

GPT-5-Codex mặc định có thẩm mỹ mạnh mẽ và các thực hành giao diện người dùng hiện đại tốt nhất. Nếu bạn có thư viện hoặc framework ưa thích, hãy điều chỉnh mô hình bằng cách thêm các phần ngắn:

Hướng Dẫn Giao Diện Người Dùng
Sử dụng các thư viện sau trừ khi người dùng hoặc repo chỉ định khác:
Framework: React + TypeScript
Styling: Tailwind CSS
Components: shadcn/ui
Icons: lucide-react
Animation: Framer Motion
Charts: Recharts
Fonts: San Serif, Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

Prompt Tham Chiếu: Codex CLI

Dưới đây là prompt đầy đủ của Codex CLI mà bạn có thể sử dụng làm tham chiếu khi tạo prompt cho GPT-5-Codex:

Các Điểm Chính Trong Prompt Codex CLI:

1. Cấu hình chung:

  • Các đối số của shell sẽ được truyền cho execvp()
  • Hầu hết các lệnh terminal nên được prefix với ["bash", "-lc"]
  • Luôn đặt tham số workdir khi sử dụng hàm shell
  • Ưu tiên sử dụng rg thay vì grep vì nhanh hơn

2. Ràng buộc chỉnh sửa:

  • Mặc định sử dụng ASCII khi chỉnh sửa hoặc tạo file
  • Thêm comment code ngắn gọn giải thích những gì đang diễn ra
  • Có thể ở trong git worktree bẩn – KHÔNG BAO GIỜ revert các thay đổi hiện có

3. Công cụ lập kế hoạch:

  • Bỏ qua công cụ planning cho các tác vụ đơn giản (khoảng 25% dễ nhất)
  • Không tạo kế hoạch một bước
  • Cập nhật kế hoạch sau khi hoàn thành một trong các subtask

4. Sandboxing và approvals:

  • Sandboxing hệ thống file: chỉ đọc, ghi workspace, truy cập đầy đủ nguy hiểm
  • Sandboxing mạng: hạn chế, bật
  • Chính sách phê duyệt: không tin tưởng, khi thất bại, theo yêu cầu, không bao giờ

5. Cấu trúc và phong cách:

  • Văn bản thuần túy; CLI xử lý định dạng
  • Tiêu đề: tùy chọn; Title Case ngắn (1-3 từ) trong …
  • Dấu đầu dòng: sử dụng -; hợp nhất các điểm liên quan
  • Monospace: backticks cho lệnh/đường dẫn/biến môi trường/id code

Apply Patch

Như đã chia sẻ trước đó trong hướng dẫn GPT-5, đây là triển khai apply_patch cập nhật nhất mà chúng tôi khuyến nghị sử dụng cho việc chỉnh sửa file để khớp với phân phối huấn luyện.

Lợi Ích Của Việc Sử Dụng Đúng Cách

  1. Hiệu Suất Cao Hơn: Phản hồi nhanh và chính xác
  2. Tiết Kiệm Token: Giảm chi phí sử dụng (40% ít token hơn GPT-5)
  3. Kết Quả Tốt Hơn: Mô hình tập trung vào nhiệm vụ chính
  4. Dễ Bảo Trì: Prompt ngắn gọn dễ hiểu và chỉnh sửa
  5. Tự Động Hóa: Suy luận thích ứng và lập kế hoạch tự động
  6. Tích Hợp Sẵn: Nhiều best practices đã được tích hợp sẵn

Kết Luận

GPT-5-Codex đại diện cho một bước tiến lớn trong việc ứng dụng AI cho lập trình. Việc áp dụng đúng các nguyên tắc prompting sẽ giúp bạn tận dụng tối đa sức mạnh của mô hình này. Hãy nhớ rằng “ít hơn là tốt hơn” – đây không chỉ là nguyên tắc của GPT-5-Codex mà còn là triết lý trong việc tạo ra các hệ thống AI hiệu quả.

Getting Started with Claude Code Spec Workflow: A Practical Guide to Spec-Driven Development

Posted on by Thưởng Đồng

In modern software development, one of the biggest challenges is keeping requirements, design, and implementation aligned. Too often, teams jump straight into coding without a solid specification, leading to rework, misunderstandings, and bugs. That’s where spec-driven development comes in — an approach that places clear specifications at the heart of the workflow.

1. What is Spec-Driven Development?

Before diving into the tool, let’s clarify spec-driven development. This is a software development approach where specifications play a central role. They are created clearly before coding begins, and every step afterward (design, task breakdown, implementation, testing) follows those specifications.

1.1 Core Principles

  • Clear specifications before coding: Requirements, acceptance criteria, architecture, and tasks must be defined before writing any logic.

  • Traceability: Each piece of code and each task can be traced back to the original spec — from requirements → design → tasks → code → testing.

  • Role clarity: Business analysts, product managers, architects, and developers contribute to specs and follow them.

  • Automation & tooling: To reduce errors and repetitive work, tools can generate tasks, skeleton code, and tests directly from specs.

  • Spec-driven testing: Verification/validation is built around acceptance criteria defined in the specs.

   Advantages:

  • Reduced risk of misinterpreting requirements

  • Easier maintenance and scalability due to clear documentation

  • Transparency between business and dev teams

  • Supports automation

   Challenges:

  • Requires discipline and upfront time to write good specs

  • Demands strong design/translation skills

  • Can feel rigid if specs are frequently changing

2. Introducing Claude Code Spec Workflow

This toolkit, built on Claude Code (Anthropic), automates workflows for spec-driven development — both feature development and bugfix processes. See GitHub: claude-code-spec-workflow.

2.1 Goals & Vision

  • Provide structured workflows for both new features and bug fixes

  • Create scaffolding with slash commands, agents, templates, and dashboards

  • Optimize context sharing to reduce token costs

  • Zero-configuration support for multiple languages (Node.js, Python, Java, etc.)

  • Real-time dashboards to monitor specs, tasks, and bugfixes

2.2 Key Features

Feature Description
Zero Configuration Detects project type (Node.js, Python, Java, etc.) automatically.
Interactive Setup User-friendly CLI prompts and error handling.
Smart File Management Generates .claude/ folder with subfolders for commands, specs, bugs, templates, agents.
Feature Workflow /spec-create feature-name "Description" generates requirements → design → tasks → implementation steps.
Bugfix Workflow Commands like /bug-create, /bug-analyze, /bug-fix, /bug-verify.
Specialized Agents AI agents for executing, validating, and analyzing specs/tasks.
Context Optimization Shares context smartly across steps, reducing token usage by 60-80%.
Real-Time Dashboard Web interface to track progress with WebSockets.
Dashboard Sharing Securely share dashboards via HTTPS tunnel with optional password.
Steering Documents Project-wide guidance docs: product.md, tech.md, structure.md.
CLI Commands ~10 slash commands for spec/bug workflows, task execution, status checks.
Claude Integration Designed for Claude Code (Opus for specs, Sonnet for implementation).

Note: This version will see fewer updates, as the author is moving toward the MCP-based version.

3. Trying Claude Code Spec Workflow

3.1 Requirements

  • Node.js ≥ 16

  • Claude Code installed & configured

  • A project directory to initialize

3.2 Installation

  1. Install globally:

    npm install -g @pimzino/claude-code-spec-workflow

  2. Check version:

    claude-code-spec-workflow --version

  3. Run setup in your project:

    cd /path/to/project
     claude-code-spec-workflow

    → Creates .claude/ folder with subfolders for specs, bugs, commands, etc.
    setup

  4. (Optional) Generate steering docs:

    /spec-steering-setup

3.3 Workflows

   a. Feature Workflow

  • Create a spec:

    /spec-create feature-name “Description”

    → Generates requirements, design, tasks. Eg: /spec-create signup “Create a REST API for signup with JWT”
    spec excute

  • Execute tasks:

    /spec-execute <id> <feature-name>

    or individual auto-generated task commands. Eg: /spec-execute signup
    spec excute

  • Check status:

    /spec-status
    /spec-list

   b. Bug Workflow

  • Create bug:

    /bug-create issue-name “Description”
    Eg: /bug-create validate-password “Password must be 8 characters long and
    include lowercase letters, uppercase letters, numbers, and special characters”

    bug create

  • Analyze: /bug-analyze
    bug analyze

  • Fix: /bug-fix
    bug fix

  • Verify: /bug-verify

  • Status: /bug-status

3.4 Behavior (per docs)

  • /spec-create calls Claude to draft requirements, designs, and tasks.

  • With task agents enabled, code or skeleton implementations are auto-generated.

  • Optimized context caching saves tokens.

  • claude-spec-dashboard launches a real-time dashboard, optionally shareable via HTTPS.

4. Observations

Strengths

  • Enforces spec-driven discipline

  • Automates repetitive steps (specs, tasks, code skeletons)

  • Improves project traceability and transparency

  • Real-time dashboard for progress tracking

  • Token-efficient context handling

Considerations

  • Depends heavily on Claude’s quality and your prompts

  • Critical architecture/design still requires human review

  • Specs need careful versioning, especially in dynamic teams

  • This Claude Code version will be less updated than the MCP one

10 Hạn Chế Của Hệ Thống RAG Chatbot: Bạn Cần Biết Trước Khi Ứng Dụng

Posted on by Phan Thanh Giảng

Trong vài năm trở lại đây, RAG (Retrieval-Augmented Generation) nổi lên như một giải pháp “cứu cánh” cho các hệ thống chatbot. Nếu chatbot truyền thống hoặc các mô hình ngôn ngữ lớn (LLM) thường mắc lỗi “nói bừa”, thì RAG ra đời để khắc phục nhược điểm đó. Nó hoạt động bằng cách kết hợp hai bước:

  1. Retriever – tìm kiếm thông tin liên quan trong kho dữ liệu (vector database, search engine, tài liệu nội bộ).

  2. Generator – sử dụng LLM để tạo câu trả lời dựa trên đoạn văn bản được tìm thấy.

Kết quả là chatbot vừa có khả năng sinh ngôn ngữ tự nhiên, vừa có kiến thức được cập nhật từ tài liệu thực tế.

Nghe rất hấp dẫn, đúng không? Nhưng đừng vội nghĩ rằng RAG là “vũ khí toàn năng”. Trong thực tế triển khai, hệ thống này vẫn tồn tại khá nhiều hạn chế mà nếu không biết trước, bạn sẽ dễ gặp thất vọng. Hãy cùng mình đi sâu vào 10 hạn chế lớn nhất của RAG chatbot.

1. Phụ Thuộc Vào Chất Lượng Dữ Liệu

RAG giống như một đầu bếp giỏi nhưng lại phụ thuộc hoàn toàn vào nguyên liệu. Nếu nguyên liệu (tức dữ liệu) không tươi ngon, món ăn sẽ không ngon.

  • Nếu tài liệu chứa lỗi chính tả, thông tin lỗi thời hoặc mâu thuẫn, chatbot sẽ trả lời sai.

  • Ví dụ: Hỏi “Chính sách bảo hiểm năm nay thế nào?” nhưng dữ liệu trong kho vẫn là quy định năm ngoái → câu trả lời sẽ lỗi thời.

👉 Bài học: Trước khi triển khai RAG, hãy đầu tư nhiều công sức vào làm sạch, chuẩn hóa và cập nhật dữ liệu.

2. Khó Xử Lý Câu Hỏi Phức Tạp, Đa Chiều

RAG giỏi trả lời những câu hỏi đơn giản, trực tiếp. Nhưng với những câu hỏi cần logic nhiều bước, hệ thống thường “đuối sức”.

Ví dụ:

  • Dữ liệu có ghi: “Ứng dụng A lưu dữ liệu trên cloud. Cloud được mã hóa AES. AES chống tấn công mạng.”

  • Câu hỏi: “Ứng dụng A làm gì để chống tấn công mạng?”

  • Chatbot dễ chỉ trả lời: “Ứng dụng A lưu dữ liệu trên cloud” và bỏ qua mối liên hệ với AES → dẫn đến câu trả lời mơ hồ.

👉 Bài học: Đừng kỳ vọng RAG thay thế khả năng lập luận sâu. Nếu cần reasoning phức tạp, bạn phải kết hợp thêm công cụ suy luận khác.

3. Không Giỏi Trả Lời Câu Hỏi Tổng Hợp

Hãy thử hỏi một câu như: “Một lập trình viên cần học gì để phát triển sự nghiệp?”.

  • Để trả lời đầy đủ, chatbot cần đề cập đến cả kỹ năng chuyên môn (AI, bảo mật…), kỹ năng mềm (giao tiếp, teamwork) và xu hướng công nghệ.

  • Nhưng RAG thường chỉ lấy được một vài đoạn văn bản ngắn → câu trả lời chỉ tập trung vào một mảng nhỏ, không toàn diện.

👉 Bài học: Với câu hỏi cần tổng quan, RAG dễ bỏ sót ý quan trọng. Bạn nên kết hợp với cơ chế tổng hợp nhiều nguồn hoặc dùng LLM để tạo outline trước.

4. Hạn Chế Với Dữ Liệu Phi Cấu Trúc (bảng, hình, code)

RAG chỉ đọc được chữ. Nó không hiểu bảng biểu, sơ đồ hay hình ảnh.

Ví dụ: Nếu bạn hỏi “Sơ đồ luồng dữ liệu này nói gì?”, chatbot chỉ có thể đọc phần caption, chứ không thể giải thích các mũi tên, ô vuông trong hình.

👉 Bài học: Nếu dữ liệu của bạn chứa nhiều biểu đồ, bảng, sơ đồ kỹ thuật… thì RAG chưa phải lựa chọn tối ưu.

5. Nguy Cơ “Hallucination” Vẫn Tồn Tại

Mặc dù RAG được quảng cáo là giảm ảo giác, thực tế thì không thể loại bỏ hoàn toàn.

Ví dụ: Hỏi “Hàm sort() trong Python hoạt động thế nào?”

  • Chatbot có thể trả lời đúng cách hoạt động.

  • Nhưng nó cũng có thể thêm cả thông tin về sort trong Java hoặc QuickSort – thứ mà bạn không hỏi.

👉 Bài học: Luôn cảnh giác. Nếu chatbot cung cấp thông tin quan trọng, cần kiểm chứng lại với nguồn dữ liệu.

6. Chi Phí Tính Toán Cao

Một RAG chatbot không chỉ cần LLM mà còn cần cơ sở dữ liệu vector + retriever.

Điều này đồng nghĩa:

  • Tốn bộ nhớ để lưu index.

  • Tốn thời gian để tìm kiếm trước khi sinh văn bản.

  • Nếu dữ liệu quá lớn → chi phí hạ tầng tăng mạnh, đặc biệt khi người dùng tăng.

👉 Bài học: Đừng quên tính toán chi phí dài hạn. Đôi khi một hệ thống FAQ truyền thống có thể đủ tốt hơn là xây RAG.

7. Không Xử Lý Tốt Dữ Liệu Thời Gian Thực

Nếu bạn hỏi: “Tỷ giá USD/VND hôm nay là bao nhiêu?” thì RAG sẽ… bó tay.

  • Vì dữ liệu trong kho thường là tĩnh, không cập nhật real-time.

  • Để làm được điều này, hệ thống phải liên tục crawl dữ liệu và re-index → rất tốn kém.

👉 Bài học: RAG phù hợp với tri thức ổn định (manual, quy định, hướng dẫn), không phù hợp với dữ liệu biến động hàng giờ.

8. Bảo Mật & Quyền Riêng Tư

Một rủi ro khác ít được nhắc tới: lộ dữ liệu nội bộ.

  • Nếu bạn đưa hợp đồng, báo cáo, tài liệu mật vào vector DB mà không kiểm soát truy cập, nhân viên có thể dùng chatbot để lấy thông tin mà lẽ ra họ không được xem.

👉 Bài học: Luôn kết hợp kiểm soát quyền truy cập và mã hóa dữ liệu khi triển khai RAG trong doanh nghiệp.

9. Khó Kiểm Soát Giọng Văn & Độ Nhất Quán

Cùng một câu hỏi, đôi khi chatbot trả lời rất chi tiết, đôi khi lại sơ sài. Điều này phụ thuộc vào đoạn dữ liệu mà retriever lấy được.

👉 Bài học: Nếu bạn cần một giọng văn thống nhất (ví dụ trong marketing, chăm sóc khách hàng), cần huấn luyện thêm phần sinh văn bản để đảm bảo consistency.

10. Thách Thức Khi Triển Khai Thực Tế

Ngoài các vấn đề trên, doanh nghiệp còn gặp phải:

  • Khó tích hợp: Kết nối RAG với CRM, ERP, API nội bộ phức tạp.

  • Đo lường hiệu quả: Khó đánh giá chatbot có thật sự trả lời “đúng” ý người dùng không.

  • Khả năng mở rộng: Khi người dùng tăng, độ trễ tăng, chi phí bùng nổ.

  • Đa ngôn ngữ: RAG hoạt động tốt với tiếng Anh, nhưng yếu hơn với ngôn ngữ ít phổ biến.

👉 Bài học: Đừng chỉ nghĩ đến prototype. Hãy lên kế hoạch triển khai dài hạn.

📌 Kết Luận

RAG chatbot thực sự hữu ích – nó giúp trả lời dựa trên dữ liệu thực tế, giảm bịa đặt, dễ cập nhật tri thức mới. Nhưng nó không phải là phép màu.

Để RAG hoạt động hiệu quả, bạn cần:

  • Chuẩn hóa dữ liệu đầu vào.

  • Kết hợp thêm công nghệ re-ranking, caching, guardrail kiểm duyệt.

  • Tính toán kỹ chi phí và hạ tầng.

👉 Nói cách khác, RAG là một mảnh ghép quan trọng trong hệ sinh thái AI, nhưng không phải “một mình cân tất cả”.

Event-Driven Multi-Agent Systems: Let Agents Act, Not Wait

Posted on by hello@scuti

AI is no longer just about single-use automation. The real power lies in multi-agent systems, networks of AI agents that work together, each specializing in a task but coordinating as part of a larger, intelligent system.

The fastest way to turn promising multi-agent prototypes into production systems is to make them event-driven. Replace brittle request/response chains with a shared event log and topic-based messaging so agents can react in real time, scale independently, and recover from failure by replay. Four field-tested patterns—orchestrator-worker, hierarchical, blackboard, and market-based—map cleanly onto streams (e.g., Kafka topics) and solve most coordination problems you’ll hit in the wild.

The Challenges of Multi-Agent Collaboration

AI agents don’t operate in isolation.

They need to share context, coordinate actions, and make real-time decisions — all while integrating with external tools, APIs, and data sources. When communication is inefficient, agents end up duplicating work, missing critical updates from upstream agents, or worse, creating bottlenecks that slow everything down.

Beyond communication, multi-agent systems introduce additional scaling challenges:

  • Data Fragmentation — Agents need access to real-time data, but traditional architectures struggle with ensuring consistency without duplication or loss.
  • Scalability and Fault Tolerance — As the number of agents grows, failures become more frequent. A resilient system must adapt without breaking.
  • Integration Overhead — Agents often need to interact with external services, databases, and APIs, but tightly coupled architectures make this difficult to scale.
  • Delayed Decision-Making — Many AI-driven applications, from fraud detection to customer engagement, require real-time responsiveness. But conventional request/response architectures slow this down.

 

Why multi-agent systems struggle in production

Multi-agent AI shines when specialized agents collaborate: one reasons over intent, another calls tools, another validates outputs, another enforces policy. But the moment you wire them together with synchronous calls, you create tight coupling, cascading timeouts, and opaque failure modes—exactly the problems early microservices faced before they moved to events. Agents need to react to what happened, not block each other waiting for RPCs.

Key pain points you’ll see at scale:

  • Communication bottlenecks and tangled dependencies

  • Data staleness and inconsistent context across agents

  • Fragile scaling & fault tolerance when agents come and go

  • Debuggability—it’s hard to reconstruct “who did what, when, and why” without an immutable log of event

These are precisely what event-driven design addresses.

Core idea: Agents as event processors + a shared log

Switch the mental model from “agents calling agents” to agents that consume commands/events and emit new events. Give them:

  • Input: subscriptions to topics (events/commands)

  • Processing: reasoning + tool use + retrieval over state

  • Output: new events (facts, decisions, tool results) appended to the log

With a durable, immutable event log (e.g., Kafka), you gain replay, time-travel debugging, and fan-out (many agents can react to the same event). Loose coupling drops operational complexity and lets you add/remove agents without re-wiring peers.

Four event-driven patterns you can ship today

These patterns come from distributed systems and MAS research, adapted to an event streaming backbone. Use them as building blocks rather than a religion—most real systems combine two or more.

1. Orchestrator-Worker

A central orchestrator breaks work into tasks and publishes them to a commands topic using a keying strategy (e.g., by session or customer). Workers form a consumer group, pull tasks, and publish results to a results topic. Scaling up = adding workers; failure recovery = replay from the last committed offset.

Use when: you need ordered handling per key, clear ownership of “who decides next,” and easy horizontal scale.

2. Hierarchical Agents

A tree of orchestrators: higher-level agents decompose goals into sub-goals for mid-level agents, which orchestrate leaf agents. Each layer is just a specialized orchestrator-worker pattern with its own topics, so you can evolve the tree without bespoke glue code.

Use when: problems decompose naturally (e.g., “Plan → Research → Draft → Review → Approve”).

3. Blackboard (Shared Memory)

Agents collaborate by reading/writing to a shared blackboard topic (or set of topics). Instead of point-to-point calls, each agent posts partial findings and subscribes to the evolving “state of the world.” Add lightweight schema tags (origin, confidence, step) for downstream filtering.

Use when: contributions are incremental and loosely ordered (perception → hypotheses → refinement).

4. Market-Based (Bidding)

Agents “bid” on a task by posting proposals; an aggregator selects winners after N rounds. Moving bids and awards onto topics prevents the O(N²) web of direct connections between solvers and keeps negotiation auditable.

Use when: you want competition among diverse solvers (planning, routing, pricing, ensemble reasoning).

Architecture sketch

At minimum you’ll want:

  1. Topics: agent.commands.*, agent.events.*, agent.results.*, plus domain streams (orders, alerts, leads).

  2. Schemas: JSON/Avro with versioned envelopes (type, source_agent, correlation_id, causation_id, ttl, safety_level, confidence).

  3. State: local caches or stateful processors (Flink/ksqlDB) for per-key context, backed by a durable changelog.

  4. Governance: central registry for schemas, PII tags, retention, and ACLs; redaction at the edge.

  5. Observability: trace by correlation_id; attach decision summaries to each event for auditability and evals.

From request/response to events: a practical migration path

  1. Define the agent interface as events. List the event types each agent consumes and emits. Treat these as public contracts.

  2. Introduce topics alongside your existing RPCs. Start publishing key milestones (task-created, tool-called, output-ready) even while calls remain.

  3. Move coordination out of code and into the stream. Replace “call Agent B, wait” with “publish Need:SummaryDraft and subscribe to SummaryDrafted.”

  4. Add replay-based testing. Re-feed yesterday’s log into a staging cluster to regression-test new agent policies without touching prod.

  5. Evolve toward patterns. As volume and agent count grow, snap into orchestrator-worker or blackboard to keep complexity in check.

Real-world payoffs

  • Parallelism: multiple agents respond to the same event—no coordinator bottleneck.

  • Resilience: if one agent dies, events aren’t lost; it resumes from the last offset.

  • Adaptability: add a new “critic” or “safety” agent by subscribing it to existing topics.

  • Traceability: every decision is a line in the log; audits and RCA stop being archaeology.

Pitfalls & how to avoid them

  • Schema drift → Use a schema registry and contract testing; never break consumers.

  • Unbounded topics → Set retention & compaction by domain (minutes for hot signals, days for ops, long-term in the data lake).

  • Chatty agents → Introduce back-pressure (quotas), batch low-value events, and enforce ttl.

  • Hidden coupling → If an agent can’t act without a specific peer, you’ve snuck in a request/response dependency. Refactor to events.

Example: Minimal event envelope (pseudocode)

When to pick which pattern

  • Highly structured workflows → Orchestrator-Worker

  • Goal decomposition → Hierarchical

  • Collaborative sense-making → Blackboard

  • Competitive ensemble solving → Market-Based

In practice, start orchestrator-worker for reliability, add a blackboard for shared context, then scale into hierarchical as teams/features grow

The bottom line

If you’re serious about production-grade agents, architecture matters more than model choice. Event-driven design gives agents the freedom to act while staying coordinated, observable, and resilient—mirroring the same evolution that made microservices workable at scale. Now is the time to formalize your agent interfaces as events and adopt patterns that have already proven themselves in distributed systems.

Further reading

  • Four Design Patterns for Event-Driven, Multi-Agent Systems (Confluent, Feb 19, 2025). Clear, concrete mappings of MAS patterns onto Kafka. Confluent

  • AI Agents Must Act, Not Wait (Medium, Jul 9, 2025). A crisp case for event-driven MAS and the shift away from request/response. Medium

Serena: Transform Any LLM Into a Professional Coding Agent – Save 80% Tokens, 5x Faster Development

Posted on by hello@scuti

Bạn đã bao giờ ước có một trợ lý lập trình thực sự hiểu codebase của mình, không chỉ đọc file dài dòng hay grep chuỗi, mà còn làm việc như một IDE ngay trong tay?

Đó chính là điều mà Serena mang lại.

Serena là gì?

Serena là một toolkit mạnh mẽ dành cho coding agent, có thể biến bất kỳ LLM nào bạn đang dùng thành một agent giàu tính năng, làm việc trực tiếp trên codebase. Khác với nhiều công cụ hiện tại, Serena không bị ràng buộc vào một LLM, framework hay giao diện cụ thể – bạn có thể linh hoạt sử dụng trong nhiều bối cảnh khác nhau.

🔧 Với Serena, agent của bạn có thể:

  • Truy xuất và chỉnh sửa code ở mức symbol, thay vì phải đọc toàn bộ file
  • Hiểu được mối quan hệ giữa các thành phần code, như cách một IDE chuyên nghiệp hoạt động
  • Tối ưu hiệu suất (token efficiency) khi làm việc với LLM, tiết kiệm chi phí và tăng tốc độ

🆓 Hoàn toàn miễn phí & mã nguồn mở

Serena giúp bạn khai thác tối đa khả năng của các LLM mà không tốn thêm chi phí.

Tại sao Serena quan trọng?

Hãy nghĩ về Serena như việc trao cho coding agent của bạn một “bộ công cụ IDE”: từ find_symbol, find_referencing_symbols cho đến insert_after_symbol. Điều này mở ra một kỷ nguyên mới, nơi việc tự động hóa code không chỉ dừng lại ở “tìm & thay thế chuỗi”, mà là hiểu và chỉnh sửa code như một lập trình viên thực thụ.

Cách hoạt động

Serena bản thân nó không phải là một “AI biết code” – mà là bộ công cụ giúp AI code tốt hơn. Để thực sự hoạt động, Serena cần một LLM (như Claude, GPT, Gemini…) làm “bộ não” để điều phối việc sử dụng công cụ.

Ví dụ đơn giản: bạn có thể supercharge Claude Code chỉ với một dòng lệnh trong terminal, và ngay lập tức Claude sẽ được bổ sung khả năng thao tác codebase ở mức IDE.

So sánh Workflow: Trước và Sau Serena

Tiêu chí Trước khi dùng Serena Với Serena
Cách tìm mã cần chỉnh sửa LLM phải đọc cả file hoặc cả codebase, sau đó “đoán” vị trí cần thay đổi Sử dụng công cụ như find_symbol, find_referencing_symbols để nhảy thẳng tới đoạn mã cần thao tác
Hiệu quả token Tiêu tốn nhiều token do phải nạp cả khối lượng mã lớn Tiết kiệm token, chỉ truy xuất phần liên quan
Tốc độ Chậm, vì cần nhiều bước suy luận và thao tác thủ công Nhanh hơn, nhờ thao tác trực tiếp ở mức symbol
Chất lượng mã sinh ra Dễ bị lỗi do LLM có thể bỏ sót ngữ cảnh quan trọng hoặc chỉnh sai chỗ Ổn định và chính xác hơn, nhờ cơ chế truy xuất có cấu trúc
Ứng dụng thực tế Chỉ phù hợp cho dự án nhỏ Cực kỳ hữu ích cho dự án lớn, nhiều module phức tạp

Công nghệ đằng sau Serena

Serena được xây dựng dựa trên Language Server Protocol (LSP) – chuẩn chung mà hầu hết các IDE hiện đại đều sử dụng. Nhờ đó, Serena không chỉ đọc code ở mức văn bản, mà còn hiểu được cấu trúc và ngữ nghĩa của mã nguồn: class, function, reference, symbol…

Tương tự như một developer đang thao tác trong IDE, Serena có thể:

  • Nhanh chóng tìm đúng context trong dự án lớn
  • Thực hiện chỉnh sửa có chủ đích, thay vì tìm kiếm chuỗi mù quáng
  • Giúp tiết kiệm token, tăng tốc độ và giảm lỗi khi kết hợp cùng LLM

💡 Kết quả: Serena thường mang lại hiệu quả cao hơn cả những giải pháp thương mại đắt đỏ, nhưng hoàn toàn miễn phí & open-source.

Ngôn ngữ được hỗ trợ

Ngôn ngữ Ghi chú
Python Hỗ trợ trực tiếp
TypeScript / JavaScript Hỗ trợ trực tiếp
PHP Dùng Intelephense LSP (cần INTELEPHENSE_LICENSE_KEY cho tính năng premium)
Go Cần cài gopls
R Cần cài package languageserver
Rust Dùng rust-analyzer qua rustup
C / C++ Một số vấn đề khi tìm references (đang cải thiện)
Zig Cần cài ZLS
C# Hỗ trợ trực tiếp
Ruby Mặc định dùng ruby-lsp (có thể chọn solargraph cũ)
Swift Hỗ trợ trực tiếp
Kotlin Dùng LS chính thức (pre-alpha, còn lỗi)
Java Startup chậm, có vấn đề trên macOS/Linux
Clojure Hỗ trợ trực tiếp
Dart Hỗ trợ trực tiếp
Bash Hỗ trợ trực tiếp
Lua Tự động tải lua-language-server nếu chưa có
Nix Cần cài nixd
Elixir Cần NextLS + Elixir (chưa hỗ trợ Windows)
Erlang Cần beam + erlang_ls, experimental, có thể chậm
AL Hỗ trợ trực tiếp

Cách tích hợp Serena với LLM

Serena được thiết kế linh hoạt, có thể cắm vào nhiều môi trường và workflow khác nhau:

🔹 Qua Model Context Protocol (MCP)

Serena chạy như một MCP server, dễ dàng tích hợp với:

  • 🖥 IDEs: VSCode, Cursor, IntelliJ
  • 🧩 Extensions: Cline, Roo Code
  • 💻 Terminal clients: Codex, Gemini-CLI, Qwen3-Coder, rovodev, OpenHands CLI
  • 🪄 Claude Code và Claude Desktop
  • 🌐 Local clients: OpenWebUI, Jan, Agno

🔹 Qua mcpo (bridge tool)

Dùng để kết nối Serena với những client không hỗ trợ MCP, nhưng có hỗ trợ tool calling qua OpenAPI (ví dụ ChatGPT).

🔹 Nhúng trực tiếp vào agent framework

Các tool trong Serena được xây dựng độc lập với framework → bạn có thể đưa vào bất kỳ agent framework nào (LangChain, LlamaIndex, v.v.), như một “plugin” chuyên về code.

💡 Điểm mạnh: Serena không khóa bạn vào một LLM hay IDE cụ thể. Dù bạn dùng ChatGPT, Claude, Gemini hay bất kỳ model nào, Serena đều có thể biến LLM đó thành một coding agent mạnh mẽ.

Hướng dẫn cài đặt Serena MCP trên Cursor (macOS)

🔹 Bước 1: Cài đặt uvx

Chạy lệnh trong Terminal:

brew install uvx

🔹 Bước 2: Thêm Serena MCP vào Cursor

  1. Mở Cursor Settings
  2. Vào mục MCP → Thêm mới MCP
  3. Trong file mcp.json, thêm cấu hình sau:
{
  "mcpServers": {
    "serena": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena",
        "start-mcp-server",
        "--context",
        "ide-assistant"
      ]
    }
  }
}

🔹 Bước 3: Kiểm tra Serena đã chạy thành công

  1. Sau khi restart Cursor, Serena MCP server sẽ được khởi động tại localhost
  2. Bạn có thể mở trình duyệt và truy cập: 👉 http://127.0.0.1:24282/dashboard/index.html
  3. Tại đây sẽ hiển thị dashboard của Serena, xác nhận rằng server đã chạy

⚡️ Giờ thì bạn có thể bắt đầu sử dụng Serena trực tiếp trong Cursor, tận dụng các công cụ phân tích code và chỉnh sửa thông minh giống như IDE xịn + AI hỗ trợ.

Bắt đầu sử dụng Serena trong Cursor

1. Kiểm tra Serena đã kết nối

  1. Mở Command Palette (⌘ + Shift + P)
  2. Gõ:
    • MCP: List Tools → để xem danh sách tool mà Serena cung cấp
    • MCP: Call Tool → để gọi trực tiếp một tool bất kỳ từ Serena

Nếu bạn thấy các tool này, nghĩa là Serena đã được kết nối thành công.

2. Index dự án với Serena (Bước quan trọng)

  1. Mở chat với AI và nhập lệnh: 
    "Use Serena to index the entire project."
  2. Chờ Serena hoàn tất indexing (tùy project lớn/nhỏ sẽ nhanh hay chậm)
  3. Sau khi indexing xong, Serena sẽ hiểu toàn bộ codebase ở mức symbol-level

3. Chat AI trong Cursor với Serena

Không dùng Serena (AI tự đoán):

"Find where process_audio_file_url is used."

Dùng Serena (AI gọi đúng tool):

"Use Serena to find where process_audio_file_url is referenced."
"Insert a new function after the UserService class using Serena."

Quan sát: Thay vì đọc toàn file, AI sẽ gọi Serena để tìm chính xác vị trí cần chỉnh sửa → tiết kiệm token, nhanh hơn và code chất lượng hơn.

Hiểu về thư mục memories/

Sau khi dùng “Use Serena to index the entire project.”, Cursor sẽ có thêm 1 thư mục memories/.

📂 Thư mục memories dùng để làm gì?

Khi bạn bảo Serena index dự án, nó sẽ quét toàn bộ codebase và trích xuất ra thông tin ở mức symbol-level (class, function, biến, module, dependency, …). Những dữ liệu này không chỉ dùng trong một session, mà được lưu trữ lại trong thư mục memories/ để tái sử dụng.

🔹 Chức năng chính của thư mục memories

  1. Lưu trữ index codebase đã phân tích
    • Thay vì phải index lại toàn bộ project mỗi lần mở Cursor, Serena sẽ đọc từ memories/ để tiết kiệm thời gian
    • Với project lớn (hàng nghìn file), điều này cực kỳ quan trọng
  2. Giúp Serena “ghi nhớ” ngữ cảnh codebase qua nhiều phiên làm việc
    • Cho phép Serena hiểu liên kết giữa các file, dependency, và symbol
    • Nhờ đó khi bạn quay lại project, Serena vẫn có thể truy vấn chính xác mà không cần quét lại từ đầu
  3. Tăng tốc độ tìm kiếm và chỉnh sửa code
    • Khi bạn gọi tool như find_symbol, Serena sẽ tìm trực tiếp trong dữ liệu memories thay vì đọc toàn bộ file
    • Điều này làm giảm đáng kể chi phí token và cải thiện tốc độ phản hồi
  4. Cơ chế cập nhật thông minh
    • Nếu bạn chỉnh sửa hoặc thêm file mới, Serena có thể cập nhật lại memories (re-index incrementally) thay vì làm lại toàn bộ
    • Giúp giữ bộ nhớ luôn đồng bộ với trạng thái codebase hiện tại

🔹 Khi nào cần xoá hoặc làm mới memories/?

  • Khi project có thay đổi cấu trúc lớn (ví dụ: đổi tên thư mục gốc, refactor nhiều module cùng lúc)
  • Khi Serena trả về kết quả sai lệch → có thể do bộ nhớ cũ. Lúc này chỉ cần xóa thư mục memories/ và chạy lại indexing

👉 Nói đơn giản: memories là “bộ não dài hạn” của Serena. Nó cho phép AI làm việc hiệu quả như một IDE, không mất công quét lại dự án mỗi lần bạn mở Cursor.

Quản lý & Làm mới thư mục memories

Đôi khi project thay đổi nhiều, hoặc Serena trả kết quả chưa chính xác → bạn có thể cần làm mới (refresh) thư mục memories/.

🔹 1. Re-index toàn bộ project

Trong chat với AI trong Cursor, gõ:

"Use Serena to re-index the entire project."

Serena sẽ xoá index cũ trong memories/ và quét lại toàn bộ codebase.

🔹 2. Cập nhật incremental (khi thêm file/hàm mới)

Nếu bạn chỉ thêm vài file mới hoặc sửa một phần nhỏ, không cần index lại hết. Hãy chat với AI:

"Use Serena to update index for changed files only."

Serena sẽ scan phần thay đổi và cập nhật lại memories/ thay vì làm lại từ đầu.

🔹 3. Xoá thủ công thư mục memories/

Trong trường hợp nghi ngờ index bị lỗi hoặc không đồng bộ:

  1. Thoát Cursor
  2. Xoá thư mục memories/ trong project: rm -rf memories
  3. Mở lại Cursor và yêu cầu: "Use Serena to index the entire project."

→ Serena sẽ tạo lại bộ nhớ mới sạch sẽ.

✅ Khi nào nên refresh memories?

  • Project refactor lớn, đổi cấu trúc folder
  • Serena tìm nhầm symbol hoặc không thấy hàm/class mới thêm
  • Project import dependency mới hoặc xoá nhiều module cũ

Case Study: Serena thay đổi game như thế nào? 🚀

1. Câu chuyện thực tế

Trong dự án Realtime Translator của công ty, mình sử dụng Claude 4 để hỗ trợ code (sau 2 tuấn để test và thực nghiệm) . Claude 4 rất mạnh về suy luận và viết code, nhưng có một nhược điểm chí mạng: ngốn token khủng khiếp.

Trước khi dùng Serena → chỉ 7 ngày là đã hết quota. Sau khi dùng Serena → tận 2 tuần vẫn chưa hết quota.

Tại sao? Vì mỗi lần yêu cầu AI chỉnh sửa code, nó phải “cày” qua hàng ngàn dòng code không liên quan, đọc cả những file chẳng liên quan gì đến yêu cầu.

👉 Điều này dẫn đến:

  • Tốn token vô ích
  • Phản hồi chậm
  • Độ chính xác giảm vì ngữ cảnh bị nhiễu loạn

Serena ra đời chính là để giải quyết nỗi đau này!

2. Những lợi ích cụ thể

🔥 Hiệu suất & độ chính xác vượt trội

AI không còn bị “ngợp” bởi hàng đống code vô nghĩa. Ngữ cảnh gọn gàng → phản hồi nhanh, chính xác, ít nhầm lẫn.

💸 Tiết kiệm chi phí và tokens

Thay vì để AI đọc cả codebase, chỉ những phần liên quan mới được đưa vào. Với các mô hình tính phí dựa trên token (như Claude, GPT-4), bạn sẽ tiết kiệm được một khoản lớn.

Cá nhân mình dùng Claude Code Pro ($17), trước kia rất dễ chạm limit. Từ ngày có Serena → vẫn còn chạm limit, nhưng đã cải thiện đáng kể

Lưu ý quan trọng khi sử dụng Serena

🔹 Cài đặt theo từng dự án

  • Serena nên được cài theo từng dự án (per-project)
  • Không nên cài ở scope “user” vì dữ liệu index có thể bị lẫn lộn giữa các project
  • Mỗi khi chuyển project, hãy đảm bảo Serena được cấu hình riêng biệt

🔹 Indexing định kỳ

  • Với project thay đổi thường xuyên, nên re-index ít nhất 1 tuần/lần
  • Khi add/remove nhiều dependency, luôn chạy lại indexing

🔹 Monitoring hiệu suất

  • Theo dõi dashboard Serena để đảm bảo server hoạt động ổn định
  • Nếu thấy phản hồi chậm, kiểm tra lại cấu hình MCP và memory usage

Kết luận

Serena không chỉ là một công cụ, mà là một game changer cho cách chúng ta làm việc với AI trong lập trình. Bằng cách biến LLM thành một coding agent thực sự hiểu codebase, Serena mở ra những khả năng mới:

  • Tiết kiệm chi phí đáng kể khi sử dụng LLM
  • Tăng tốc độ và độ chính xác trong các tác vụ coding
  • Mở rộng khả năng của AI từ “code generator” thành “code collaborator”

Và quan trọng nhất, tất cả điều này đều hoàn toàn miễn phí và mã nguồn mở.

👉 Hành động ngay hôm nay: Hãy thử cài đặt Serena cho project của bạn và trải nghiệm sự khác biệt. Bạn sẽ ngạc nhiên về hiệu quả mà nó mang lại!

Bài viết được viết dựa trên trải nghiệm thực tế sử dụng Serena trong các dự án production. Để biết thêm thông tin chi tiết và cập nhật mới nhất, hãy truy cập GitHub repository của Serena.

© 2015 - 2025 Scuti. All rights reserved.