Bạn khởi chạy ba coding agent cho ba nhiệm vụ, rồi dành hai mươi phút tiếp theo để chuyển qua lại giữa các tab terminal, cố trả lời một câu hỏi duy nhất: cái nào đang cần tôi ngay bây giờ? Một cái vẫn đang chạy. Một cái đang chờ một lệnh y/n mà bạn chưa từng thấy. Một cái đã thoát với trạng thái xanh từ một giờ trước và âm thầm tạo ra thứ sai. Không có gì báo cho bạn bất kỳ điều nào trong số đó. Bạn phải tự đi tìm.
Khoảng trống đó chính là thứ mà khả năng quan sát coding agent (coding agent observability) được kỳ vọng sẽ lấp đầy. Observability, vay mượn từ ngành kỹ thuật hệ thống, là khả năng hiểu một tiến trình đang chạy làm gì dựa trên các tín hiệu nó phát ra, mà không cần gắn trực tiếp vào nó (OpenTelemetry có một bài giới thiệu nhập môn rất tốt). Với coding agent, tiêu chuẩn là: bạn phải có khả năng trả lời câu hỏi “mỗi agent đang làm gì, cái gì đã thất bại, và cái gì cần đến con người” từ một góc nhìn chung, chứ không phải bằng cách theo dõi (tail) một phiên làm việc. Hầu hết các thiết lập đều không làm được. Họ có một trạng thái ở đâu đó và một log ở đâu đó, rồi gọi đó là observability. Không phải vậy.
Bài viết này điểm qua ba tín hiệu mà một coding agent thực sự phát ra, những tín hiệu thất bại nào đáng để gắn cảnh báo, và nơi mà một lớp nhiệm vụ chung như Sharkly biến output thô thành thứ bạn có thể hành động dựa trên. Sharkly nằm phía trên các agent bạn đang chạy; bạn đã có coding agent rồi, và điểm mấu chốt ở đây là làm cho công việc của chúng trở nên dễ đọc hiểu khi có nhiều hơn một agent.
Status, log và tín hiệu thất bại là ba thứ khác nhau
Ba từ này thường bị dùng lẫn lộn, và sự nhầm lẫn đó chính là gốc rễ của hầu hết các thiết lập giám sát tồi. Chúng trả lời những câu hỏi khác nhau.
Status là trạng thái tóm tắt của một lượt chạy. Đang chạy, đang chờ input, đã xong, hoặc đã thất bại. Đó là một trường duy nhất, đọc rất rẻ, và nó cho bạn biết lượt chạy đang ở đâu, chứ không phải nó đã làm gì. Status không phải là observability; nó chỉ là sự thật nhỏ nhất về một lượt chạy.
Log là dấu vết thực thi thô. Mọi lần gọi công cụ, chỉnh sửa tệp, và phản hồi của mô hình, theo thứ tự. Log cho bạn biết điều gì đã xảy ra sau khi bạn đã biết là có gì đó sai. Chúng không thể thiếu cho việc kiểm tra hậu sự cố (post-mortem) và vô dụng như một tín hiệu trực tiếp, vì không ai ngồi xem năm log đang cuộn cùng lúc. Một log không phải là tín hiệu cho đến khi có thứ gì đó rút ra được ý nghĩa từ nó.
Tín hiệu thất bại là những cảnh báo được suy ra. Chúng là những điều kiện cụ thể đáng để ngắt ngang bạn: một agent bị kẹt, một lượt chạy báo xanh nhưng đi sai hướng, ngân sách cạn giữa nhiệm vụ. Tín hiệu thất bại mới là thứ bạn thực sự muốn, và đó là lớp mà gần như mọi thiết lập tự chế đều bỏ qua, bởi để suy ra nó thì phải xử lý log thành sự kiện, chứ không chỉ lưu trữ chúng.
Cái bẫy là dừng lại ở hai lớp đầu. Status cộng log có vẻ giống observability vì bạn có một trạng thái và một bản ghi. Nhưng câu hỏi duy nhất có thể mở rộng được, “agent nào của tôi đang cần tôi?”, lại nằm hoàn toàn ở lớp thứ ba.
Những tín hiệu thất bại thực sự quan trọng
Observability của dịch vụ web theo dõi các sự cố sập và độ trễ. Coding agent thất bại theo cách khác, và những thất bại khiến bạn mất cả buổi chiều hiếm khi là những cái hiện ra dưới dạng trạng thái đỏ. Đây là những tín hiệu đáng để suy ra.
| Tín hiệu | Ý nghĩa | Vì sao status và log bỏ sót nó |
|---|---|---|
| Kẹt im lặng | Agent đang chờ một prompt hoặc một secret còn thiếu, không tạo ra output | Status vẫn hiển thị “đang chạy”; không có gì giơ tay báo động |
| Xanh nhưng sai | Lượt chạy thoát thành công nhưng làm sai việc | Status là “đã xong”; chỉ đọc diff mới phát hiện ra |
| Bỏ qua bước kiểm chứng | Báo đã xong mà không chạy typecheck, test, hoặc build | Log có chứa sự thiếu sót đó, nhưng không ai đọc một log báo pass |
| Cạn ngân sách | Hạn mức mô hình hoặc trần chi tiêu bị chạm giữa chừng nhiệm vụ | Thất bại hiện ra dưới dạng phản hồi bị cắt ngắn, chứ không phải một cảnh báo |
| Xung đột tiềm ẩn | Hai agent chỉnh sửa cùng những tệp trong các worktree riêng biệt | Cả hai lượt chạy đều “đã xong”; va chạm sẽ chờ đến lúc merge |
| Thrash (quẩn quanh) | Agent sửa, hoàn tác, rồi sửa lại cùng một tệp trong một vòng lặp | Mọi bước riêng lẻ đều trông ổn trong log |
Điểm chung của cả sáu tín hiệu: thất bại vô hình ở lớp status và bị chôn vùi ở lớp log. “Xanh nhưng sai” là cái bị đánh giá thấp nhất. Một coding agent tự tin hoàn thành sai nhiệm vụ trông y hệt như một cái làm đúng, cho đến tận khi việc review với bằng chứng ở cấp nhiệm vụ phát hiện ra. Observability chỉ báo mã thoát (exit code) sẽ báo thất bại đó là thành công.
Hai trong số này mang tính cấu trúc chứ không phải hành vi. Xung đột tiềm ẩn là lý do công việc song song trên cùng một repo cần các worktree được cô lập cho mỗi nhiệm vụ, để các tệp chồng lấn hiện ra trước khi merge thay vì trong lúc merge. Cạn ngân sách là lý do việc theo dõi chi tiêu trên các agent thuộc về cùng một góc nhìn với status; một lượt chạy âm thầm dừng lại vì hết hạn mức là một tín hiệu thất bại, chứ không phải một nhiệm vụ đã hoàn thành.
Bạn cần bao nhiêu observability, tùy theo quy mô nhóm
Bạn không cần cả sáu tín hiệu ngay từ ngày đầu. Mức độ đo lường phù hợp tỉ lệ thuận với số lượng agent đang chạy và số người cần nhìn thấy chúng.
| Thiết lập | Cần đo lường gì | Chỗ nào sẽ vỡ |
|---|---|---|
| Một agent, một nhiệm vụ | Chỉ status; đọc log nếu nó thất bại | Không có gì, cho đến khi bạn khởi chạy agent thứ hai |
| Vài agent đơn lẻ | Status cho mỗi lượt chạy, cộng tín hiệu kẹt và xanh nhưng sai | Bạn suy đoán trạng thái từ sự im lặng và bỏ sót các lần kẹt |
| Nhóm nhỏ, repo dùng chung | Cả sáu tín hiệu, cộng trạng thái review, trong một góc nhìn chung | Việc giám sát của bạn nằm trên một laptop không ai khác nhìn thấy |
| Nhóm lớn hơn, nhiều repo | Những thứ trên cộng quyền sở hữu từng lượt chạy, ngân sách, và dấu vết kiểm toán | Không ai trả lời được “ai đã chạy cái gì” sau một tuần |
Cách hiểu trung thực: một lập trình viên đơn lẻ chạy một agent cho công việc không liên quan thì đã có đủ mọi observability cần thiết trong một terminal duy nhất. Phương trình thay đổi ngay khi số agent vượt qua số màn hình của bạn, khi công việc chạy trên những máy mà bạn không ngồi trực tiếp, hoặc khi một người khác cần nhìn thấy cùng một bảng. Vượt qua ranh giới đó, một trường status và một thư mục log không còn đủ nữa.
Khi nào log thô và một runtime duy nhất là đủ
Hãy để các công cụ tích hợp sẵn thể hiện phiên bản tốt nhất của chúng, bởi với rất nhiều công việc chúng thắng thế. Claude Code và Codex đều giữ một dấu vết phiên làm việc dễ đọc, và với một agent đơn lẻ cho một nhiệm vụ đơn lẻ thì dấu vết đó chính là observability của bạn. Bạn khởi chạy nó, bạn đang theo dõi nó, bạn sẽ đọc log nếu nó dừng lại. Thêm một lớp quản lý vào đó chỉ là chi phí thuần túy.
Hãy dùng chính output của runtime khi bạn chạy một hoặc hai agent, cho công việc không liên quan, không bao giờ bàn giao cho ai khác. Còn hãy tìm đến một lớp observability chung khi các lượt chạy vượt qua khả năng chú ý của bạn, khi chúng thực thi ở nơi bạn không thể theo dõi (tail), hoặc khi việc review buộc phải trở thành hoạt động của cả nhóm thay vì việc riêng tư. Trường hợp cuối cùng là kẻ giết người âm thầm: năm agent hoàn thành song song không phải là thắng lợi nếu việc review diff của chúng lại dồn về thành một hàng đợi chỉ một con người. Agent thì nhanh hơn; bạn thì chậm hơn. Đó cũng là một vấn đề observability, và không một runtime đơn lẻ nào giải quyết được, bởi tín hiệu quan trọng, “lượt chạy này đã xong và đang chờ bạn review”, nằm ở xuyên suốt các agent, chứ không nằm trong một agent.
Observability khi kết quả trở về Nhiệm vụ
Một lớp nhiệm vụ thay đổi đơn vị của observability từ “một tiến trình trong một pane” thành “một Nhiệm vụ với một trạng thái.” Đây là sự dịch chuyển mà Sharkly được xây dựng xoay quanh, và nó ánh xạ lên cả ba tín hiệu cùng một lúc.
Mỗi lượt chạy của agent gắn vào một Nhiệm vụ. Trạng thái, tiến độ, điểm tắc nghẽn, và kết quả trở về dòng thời gian của Nhiệm vụ đó thay vì nằm trong một log chỉ mình bạn thấy. Các tín hiệu thất bại hiện ra ở một nơi: những lượt chạy cần con người sẽ đáp xuống Inbox, nên câu hỏi không còn là “có cái gì đã xong chưa?” mà trở thành “đây là những gì cần tôi quyết định.” Agent nghiên cứu, thực thi, kiểm thử, và báo cáo; con người định hướng, trao quyền, và chấp nhận kết quả. Tự động hóa dừng lại ở nơi cần đến phán đoán của tập thể.
Ranh giới này quan trọng, vì rất dễ giả định sai. Sharkly không chạy agent và không viết code. Claude Code, Codex, và những runtime khác bạn đang dùng vẫn thực hiện phần thực thi. Sharkly thêm lớp nhiệm vụ chung, Computer, ngữ cảnh, và review bao quanh chúng, để ngữ cảnh, tiến độ, điểm tắc nghẽn, kết quả, và việc review của con người luôn hiển thị từ lúc đưa ra yêu cầu đến lúc phát hành. Để có bức tranh đầy đủ hơn về những gì bảng chung đó nên hiển thị, xem một dashboard coding agent AI thực sự cần những gì, và để có góc nhìn giám sát trực tiếp, xem cách giám sát các coding agent chạy song song.
Nếu bạn muốn tiếp tục dùng nhiều coding agent thay vì cam kết với một hệ sinh thái duy nhất, thì góc nhìn chung, lấy tín hiệu làm đầu đó chính là bài toán mà Sharkly được thiết kế để giải quyết. Bạn có thể chạy các coding agent hiện có của mình qua Sharkly và giữ nguyên mọi runtime bạn đang dùng.
Câu hỏi thường gặp
Observability của coding agent có giống với logging không? Không. Logging lưu lại điều đã xảy ra. Observability là khả năng trả lời mỗi agent đang làm gì, cái gì đã thất bại, và cái gì cần bạn, mà không phải đọc từng log một. Log chỉ là một đầu vào của observability, chứ không phải toàn bộ nó.
Tín hiệu thất bại quan trọng nhất nên gắn cảnh báo trước tiên là gì? Kẹt im lặng. Một agent hiển thị “đang chạy” trong khi chờ đợi mãi mãi một prompt bạn chưa từng thấy là cách phổ biến nhất khiến công việc song song âm thầm chết. Hãy làm cho những lượt chạy bị chặn giơ tay báo động trước khi bạn theo đuổi bất cứ thứ gì cầu kỳ hơn.
Tôi có thể lấy được điều này từ output tích hợp sẵn của coding agent không? Với một agent, có. Dấu vết phiên làm việc của chính runtime là đủ. Output tích hợp sẵn không có góc nhìn xuyên agent, nên nó không thể cho bạn biết lượt chạy nào trong năm lượt đang cần bạn, mà đó chính xác là câu hỏi xuất hiện khi bạn mở rộng vượt qua một agent.
