저자: @rohit4verse

올바른 모델을 찾지 못했기 때문에 잘못된 모델을 사용하고 있는 것이 아닙니다 AI.

잘못 사용했습니다 AI 올바른 환경을 구축하지 않았기 때문입니다.

어떤 팀은 세 명의 엔지니어와 함께 수백만 줄의 코드를 전달한 반면 다른 팀은 파이프라인에서 안정적인 리팩토링조차 달성하지 못합니다. 에이전트 ——이유는 GPT-5 또는 Claude Opus 온도 설정 또는 최대 토큰, 심지어 프롬프트 단어도 아닙니다. 비록 사람들이 프롬프트 단어에 대해 논쟁을 벌이는데 셀 수 없이 많은 시간을 보냈지만 말입니다.

차이점은 하네스입니다.

이 글에서 다룰 내용은 이 단어가 기술적, 개념적 수준에서 의미하는 바입니다.——업계 전체가 이 단어를 부주의하게 사용하는 나쁜 습관을 키워왔기 때문입니다.

harness 는 시스템 프롬프트 단어도 아니고 API 호출용 패키지도 아니며, 평가 프레임워크도, 프롬프트 단어 템플릿도, 메모리 기능이 있는 챗봇도 아닙니다.

하네스 언어 모델이 작동하는 완전한 디자인 환경입니다(호출할 수 있는 도구, 수신하는 정보의 형식, 기록이 압축 및 관리되는 방식, 오류를 사전에 포착하기 위한 가드레일 포함) 일관성을 잃지 않고 미래의 자신에게 작업을 넘겨줄 수 있는 비계입니다.

인류적 만약 Claude Code 실제로 작동하도록 만들어진 것 NLP 에이전트-컴퓨터 인터페이스 SWE 에이전트 에 대한 랜드마크 논문을 살펴보면 이 분야에서 진지하게 일하는 모든 팀에서 비슷한 패턴이 나타나는 것을 볼 수 있을 것입니다.

모델은 거의 관련성이 없습니다. 하네스 가 전부입니다.

다음은 2025년부터 2026년까지 이 개념이 어떻게 현실화되었는지에 대한 간략한 소개입니다. lang="EN-US"> AI 엔지니어링 핵심 통찰력에 대한 자세한 기술 분석입니다. 관련 연구, 실제 구현 사례, 설계 결정을 내리는 실패 모드, 프로그래밍 에이전트를 구축하든, 에이전트를 연구하든, 장기간 실행되는 자율 소프트웨어 엔지니어가 되든 계속해서 나타나는 패턴을 다룹니다.

읽고 나면 하네스 정의가 무엇인지 이해하게 될 뿐만 아니라 하네스를 올바르게 구축하는 이유 하네스는 오늘날 업계에서 가장 귀중한 엔지니어링 기술이 되었습니다.

제1부: 아무도 말하지 않는 문제

원시 전력만으로는 충분하지 않은 이유

2024년 올해 중순,AI벤치마킹 분야에서 이상한 일이 일어났습니다. 연구자들은 동일한 최첨단 모델이 동일한 프로그래밍 작업에 대해 작업이 제시되는 방식과 사용 가능한 도구에 따라 매우 다른 결과를 생성할 수 있다는 사실을 알아차리기 시작했습니다. 모델은 변경되지 않았고 기본 인텔리전스도 변경되지 않았으며 인터페이스만 변경되었습니다.

이것은 놀라운 일이 아닙니다. 우리는 올바른 도구가 엔지니어의 생산성을 높일 수 있다는 사실을 수십 년 동안 알고 있었습니다. 최신 IDE, 디버거, 버전 제어 및 CI/CD 파이프라인을 갖춘 소프트웨어 개발자는 동일한 사람이 텍스트 편집기만 있는 순수 터미널에서 작업하는 것보다 훨씬 더 생산적입니다. IDE는 개발자를 더 똑똑하게 만들지 않습니다. 마찰을 줄이고 적시에 정보를 표시하며 오류를 조기에 포착하고 작업을 탐색 가능한 단위로 구성합니다.

언어 모델의 경우에도 마찬가지입니다. 이는 무한한 내부 지식 기반에서 추론하는 범용 추론 엔진이 아니라 컨텍스트 창 내에서 토큰에 대해 작동하는 정교한 패턴 일치 엔진입니다. 특정 순간에 그들이 아는 모든 것은 컨텍스트 창의 내용에 따라 결정됩니다. 그들이 생산하는 모든 것은 그 맥락의 구조에 따라 결정됩니다. 입력 형식은 장식이 아니라 에이전트의 인지 아키텍처입니다 .

인터페이스는 편의 레이어가 아닙니다. 언어 모델 에이전트 의 경우 인터페이스는 마음 그 자체입니다.

여기는 프린스턴입니다 NLP 그룹 2024년 게시 대상: SWE-agent 논문의 핵심 제안은 정밀 조사를 견딜 수 있습니다. 이 문서에서는 에이전트컴퓨터 인터페이스(ACI)의 개념을 소개하고 잘 설계된 ACI 생성 64% 의 상대적인 개선.

동일한 모델, 동일한 작업, 동일한 계산 예산, 유일한 변수는 인터페이스입니다.

이 숫자를 잠시 기다려 보세요. 64% 는 한계 이익이 아니라 효과적인 도구와 비효과적인 도구 사이의 격차입니다. 이는 기본 모델의 개선이 아닌 전적으로 환경 설계에서 비롯됩니다.

컨텍스트 창이 메모리 슬롯이 아닙니다

AI 에이전트 에 대한 순진한 인지 모델은 컨텍스트 창을 메모리로 처리합니다. 데이터를 로드하고, 모델이 이를 처리하고, 출력을 얻습니다. 맥락이 많을수록 성과가 향상되고, 프롬프트가 길수록 이해도가 높아집니다. 이 정신 모델은 잘못되었으며, 잘못된 접근 방식은 이를 바탕으로 구축한 에이전트를 파괴할 것입니다.

컨텍스트 창은 실제로 특정 세션에서 에이전트 의 전반적인 작업 인식에 더 가깝습니다. 창의 각 토큰 에는 계산 비용이 있습니다. 관련 없는 모든 정보는 관심을 끌기 위해 관련 정보와 경쟁합니다. 이 모델에는 잡음을 완전히 무시할 수 있는 선택적 주의 메커니즘이 없습니다——잡음의 존재는 추론에 영향을 미칩니다.

이는 에이전트 설계에 구체적이고 측정 가능한 결과를 가져옵니다. 큰 코드 베이스에 대해 grep 루프를 실행하고 일치하는 결과의 1만 행을 반환하면 에이전트 사용 가능한 추가 정보가 제공되지 않고 관련 없는 데이터로 작업 메모리가 넘치게 됩니다. 이는 컨텍스트가 지워질 때까지 각 후속 단계의 품질을 저하시킵니다.

두 가지 기능을 보고 싶을 때 에이전트 사용 cat 전체 파일을 버리면서 물 한 잔이 필요할 때 소방 호스를 건네주었습니다.

SWE-agent 의 연구원들은 이러한 실패 모드를 자세히 문서화했습니다. 표준 bash 인터페이스로 인해 에이전트 반복 순회에 걸릴 수 있습니다. 에이전트는 grep 명령을 실행하고 길을 잃습니다. 찾고 있는 것에서 더 많은 grep 명령을 실행하고 점차적으로 컨텍스트를 소음으로 채우고 결국 잘못된 대답을 제공하거나 진행을 완전히 중단하게 됩니다.

문제는 모델 지능이 아니라 인터페이스에 에이전트 자체에 압도되는 것을 방지할 메커니즘이 없다는 것입니다.

ACI 의 솔루션은 제한되고 집계된 결과 목록을 반환하는 검색 도구를 구축하는 것입니다. 검색에서 50개 이상의 일치 항목이 반환되면 도구는 출력을 표시하지 않고 에이전트에게 쿼리 범위를 좁히도록 지시합니다.

이 디자인 결정은 돌이켜보면 거의 우스꽝스러울 정도로 단순해 보이지만 전체 논문에서 가장 활용도가 높은 변경 사항 중 하나입니다. 상황이 압도하는 실패 패턴을 자연스러운 개선의 순환으로 바꿔줍니다.

2부:SWE-Agent 종이와 ACI의 탄생

에이전트-컴퓨터 인터페이스란 정확히 무엇인가요

ACI 는 SWE-agent 언어 모델에 있는 문서 에이전트 간 추상화 계층에서 정의됩니다. 및 컴퓨터 환경. 인간-컴퓨터 인터페이스(HCI)와의 비유는 의도적인 것입니다. HCI 연구에서 인간의 인지 아키텍처에 적합한 인터페이스를 디자인하는 방법을 묻는 것처럼, ACI 연구에서는 언어 모델의 인지 아키텍처에 적합한 인터페이스를 디자인하는 방법을 묻습니다.

인간의 인지 구조에는 시각적 패턴 인식, 공간 기억, 화면 전반에 걸친 병렬 주의, 훑어보고 선택적으로 집중하는 능력이 포함됩니다.

언어 모델의 인지 아키텍처는 근본적으로 다릅니다——순서가 포함됩니다 토큰 처리, 상황별 순서 및 형식에 대한 민감도, 제한된 작업 메모리, 언어에서 가장 중요한 정보에 고정하려는 경향 큐 단어. 좋은 ACI를 설계한다는 것은 이러한 제약 조건을 이해하고 이에 반대하는 것이 아니라 이를 중심으로 구축하는 것을 의미합니다.

검색 및 탐색

검색 구성 요소는 표준 grep 및 find 명령을 대체합니다. 50 입니다.

쿼리가 이 제한을 초과하면 도구는 결과가 너무 많다는 메시지를 반환하고 에이전트 에 검색 범위를 좁히라는 메시지를 표시합니다. 이는 사소하게 들리지만 실제로는 이 논문에서 가장 영향력 있는 결정 중 하나입니다.

이것이 중요합니다. 에이전트 인지 부하를 받는 인간과 마찬가지로 에이전트도 불확실하다고 느낄 때 행동을 계속하는 경향이 있기 때문입니다. 대규모 코드 기반에서 길을 잃으면 점점 더 광범위하게 검색하게 되어 점점 더 많은 소음이 발생합니다. 제한된 검색 도구는 강제 기능을 생성하여 이러한 패러다임을 파괴합니다. 모호하게 진행해서는 안 되며 정확해야 합니다. 이로 인해 상담원은 더욱 신중하고 목표에 맞는 행동을 하게 됩니다.

파일 뷰어

파일 뷰어는 인지 아키텍처에 대한 논문의 통찰력을 가장 구체적으로 표현한 것입니다. 연구원들은 다양한 뷰어 구성을 테스트한 결과 디스플레이당 100행이 딱 맞는 숫자라는 사실을 발견했습니다. 더 적은 줄( 30 행 테스트)으로 인해 에이전트 주변 코드에 대한 컨텍스트가 손실되면 편집 오류가 발생할 수 있습니다. 줄이 더 많으면(또는 전체 파일이 표시되면) 에이전트가 방향을 잃거나 중요한 세부 정보를 놓칠 수 있습니다.

뷰어는 상태를 저장하여 상호작용 간에 파일에서 자신의 위치를 유지합니다. 더 중요한 것은 보이는 각 줄 앞에 명시적인 줄 번호를 추가한다는 것입니다. 이 마지막 세부 사항은 순전히 피상적으로 보일 수 있지만 그렇지 않습니다.

언제 상담원 메시지를 47 52에게 보내야 합니다. 줄 편집 명령을 사용하려면 행을 세거나 산술을 수행하는 대신 뷰에서 직접 이러한 숫자를 읽을 수 있어야 합니다. 에이전트의 작업 메모리에서 이 인지 작업을 제거하면 실제 문제 해결을 위한 인지 능력이 확보됩니다.

파일 편집기 Linting

파일 편집기의 핵심 혁신은 가드레일을 통한 즉각적인 피드백입니다. edit 명령은 시작 줄, 끝 줄 및 대체 텍스트를 단일 작업으로 허용합니다. 각 편집 후에 도구는 수정된 파일에 대해 자동으로 linter 를 실행하고 결과를 보고합니다. 편집으로 인해 구문 오류가 발생하면 편집이 적용되기 전에 거부되고 에이전트는 원본 코드와 실패한 편집을 모두 보여주는 명확한 오류 메시지를 받습니다.

이것은 순진한 에이전트 구현에서 연속적인 실패를 일으키는 피드백 루프를 닫습니다. linter , 에이전트 가 없는 경우 구문 오류가 발생하고, 테스트 도구 모음을 실행하고, 겉으로는 관련이 없는 오류를 확인하고(실제 오류는 다른 곳에 있기 때문에) 잘못된 문제를 추적하는 여러 단계를 거쳐 결국 컨텍스트 창 추적을 소진할 수 있습니다. 유령.

linter 를 편집기에 직접 통합하면 구문 오류가 도입되는 순간 발견될 수 있고 수정 사항이 현지화되며 문제가 전파되지 않습니다.

원본 사용 비교 bash 도구: sed 또는 출력 리디렉션 사용, 통합 피드백이 없고 편집이 자동으로 수행되며 여러 줄 수정에는 복잡한 매개변수가 필요함 오류가 발생하기 쉬운 형식입니다. 에이전트 명령을 성공적으로 실행할 수 있지만 linter 잡을 수 있는 미묘한 형식 오류가 발생하고 다음 10단계를 거쳐 테스트가 실패한 이유를 궁금해합니다.

컨텍스트 관리

네 번째 구성요소는 오랜 세션에 걸쳐 누적되는 문제, 즉 오래된 컨텍스트의 축적을 해결합니다. 에이전트가 임무를 진행함에 따라 해당 기록은 환경의 현재 상태를 더 이상 반영하지 않는 오래된 관찰, 중간 상태 및 탐색 단계로 가득 차 있습니다.

이 모든 기록은 컨텍스트 창에서 공간을 차지하며 오래된 정보를 제공하여 적극적으로 오해를 불러일으킬 수 있습니다 에이전트.

ACI 의 컨텍스트 관리 시스템은 이전 관찰을 기록합니다——마지막 5라운드 이전의 콘텐츠——한 줄 요약으로 압축되었습니다. 이는 전체 궤적의 압축된 기록을 유지하면서 최근 관련 정보에 대한 활성 컨텍스트에 초점을 맞춥니다.

에이전트 지금까지 실행한 모든 명령의 압축되지 않은 전체 기록에 압도당하지 않고도 최근에 수행한 작업과 현재 상태를 언제든지 확인할 수 있습니다.

벤치마크 결과와 그 실제 의미

SWE-agent 논문은 위에 있습니다SWE-bench 데이터 세트 ACI 벤치마킹되었습니다 인기 있는 Python 코드 베이스의 실제 GitHub 문제가 포함된 데이터세트를 대상으로 합니다. 자연어 버그 리포트를 받고 이를 해결하기 위한 코드 패치를 제작하는 것이 과제이다. 이는 익숙하지 않은 코드 기반 탐색, 오류 메시지 이해, 올바른 코드 작성 및 수정 사항 확인이 필요한 어려운 실제 작업입니다.

사용 GPT-4 표준 bash 쉘 인터페이스 사용, 시스템이 문제 해결, 시스템이 해결 12.47% 의 문제입니다. 이는 앞서 언급한 64%의 상대적 개선이며, 이는 전적으로 인터페이스 디자인에서 비롯됩니다.

또한 연구원들은 각 설계 결정의 기여도를 분리하기 위해 구성 요소를 한 번에 하나씩 제거하는 절제 연구도 수행했습니다. Linter 통합은 항상 가장 많이 활용되는 구성 요소 중 하나입니다. 제한된 검색은 컨텍스트 범람을 방지하는 데 중요합니다. 줄 번호가 있는 상태 저장 파일 뷰어는 원래 cat cat 명령과 더 단순한 뷰어 디자인보다 성능이 훨씬 뛰어납니다.

성능 차이는 모델 지능과는 아무런 관련이 없으며 모든 것은 인지 부하 관리와 관련이 있습니다. ACI 모델이 상태를 추적하는 데 필요한 작업량을 줄여 정말 중요한 작업을 위한 공간을 확보합니다.

이러한 사실은 프로그래밍 그 이상입니다 에이전트 . 모든 장기 에이전트 작업에는 동일한 기본 과제가 포함됩니다. 즉, 대규모 정보 공간 탐색, 여러 단계에 걸쳐 일관된 상태 유지, 오류 포착 및 복구, 상황별 창 주의의 제한된 리소스 관리 등이 있습니다. ACI 의 디자인 원칙은 일반화 가능합니다. 특정 도구는 변경되지만 근본적인 문제 구조는 변경되지 않습니다.

3부:인류적 의 하네스 프로젝트(장기 실행 에이전트 문제)

컨텍스트 창 경계가 핵심 퍼즐인 이유

SWE-agent 이 문서는 단일 에이전트 세션에 대한 인터페이스를 설계하는 방법에 대한 문제를 해결합니다. Anthropic 의 엔지니어링 팀은 Claude Agent SDK 및 Claude 코드를 작성하는 과정에서 다른 것을 만났습니다. 문제: 작업이 너무 커서 단일 컨텍스트 창 내에서 완료할 수 없으면 어떻게 해야 합니까?

이것은 틈새 시장 사례가 아닙니다. 대부분의 실제 소프트웨어 프로젝트는 너무 커서 컨텍스트 창에 맞지 ​​않습니다. 프로덕션급 웹 애플리케이션에는 수백 개의 파일, 수천 개의 기능, 테스트 스위트, 구성, 문서 및 종속성이 포함되어 있습니다.

20 백만 토큰 컨텍스트 창이 있어도 전체 프로젝트를 동시에 마음 속에 담을 수는 없습니다. 인간 엔지니어들은 외부 메모리, 문서화, 버전 관리, 그리고 몇 주, 몇 달에 걸쳐 코드 베이스에 축적된 이해를 통해 이 문제를 해결합니다. 그리고 새 세션을 여는 에이전트에는 아무것도 없습니다.

순진한 해결책은 어느 정도 작동하는 압축(압축)입니다. Claude Agent SDK 에는 창이 가득 찼을 때 이전 컨텍스트를 요약할 수 있는 압축 기능이 내장되어 있습니다. 그러나 압축만으로는 충분하지 않습니다.

Anthropic 의 내부 실험에 따르면 Opus 4.5

실패는 두 가지 패턴을 나타내며 둘 다 유익합니다.

첫 번째 실패 모드는한 번에 너무 많은 일을 시도하는 것입니다. 주어진 경우 "build a claude.ai clone"이러한 프롬프트 단어는 에이전트 는 전체 신청서를 한 번에 완료하려고 시도합니다.

기능을 계속해서 구현하지만 각 기능이 완료되거나 테스트되지 않아 구현 프로세스에서 컨텍스트 창을 소진하고 다음 세션에서는 절반만 완성된 애플리케이션으로 남습니다.—완료된 내용에 대한 문서도 없고 코드의 현재 상태에 대한 명확한 설명도 없습니다.

다음 에이전트 인스턴스는 앞으로 나아가기보다는 상황을 이해하는 데 대부분의 컨텍스트 예산을 소비합니다.

두 번째 실패 모드는 프로젝트 후반부에 발생합니다. 일부 기능이 구축된 후 에이전트의 후속 인스턴스는 주변을 둘러보고 진행 상황을 확인하고 작업이 완료되었다고 결론을 내립니다."의 결론. 애플리케이션이 절반만 완료되면 승리를 선언하고 작동을 중지합니다.

이것은 어리석은 것이 아니라 불완전한 정보에서 나온 합리적인 추론입니다. 에이전트 이 프로젝트에 대해 알아볼 수 있는 체계적인 방법이 없습니다."완료"정확히 무엇을 의미하나요?

두 가지 실패에는 공통 루트가 있습니다.에이전트 컨텍스트 창 경계에서 살아남을 수 없고 후속 세션에 대한 방향을 제공할 수 없는 프로젝트 상태에 대한 지속적이고 구조화된 이해가 없습니다.

더블 에이전트 아키텍처: 초기화 에이전트 및 프로그래밍 에이전트

인류적 의 솔루션은 두 부분으로 구성된 아키텍처였으며 이후 장기적인 에이전트적 작업을 진지하게 생각하는 팀을 위한 템플릿이 되었습니다.

첫 번째 부분은초기화 에이전트입니다. This is a specialized initial session with a dedicated system prompt word, and its entire purpose is to set up the environment in which all subsequent programming agent will operate.它不编写功能，它创建使得跨多个后续会话的功能开发成为可能的脚手架。

初始化 Agent 产出三个关键输出。

首先，它创建一个能够可靠启动开发环境的init.sh 脚本。这听起来平淡无奇，但具有显著的杠杆效益。

后续每一个编程agent 会话都可以通过运行 init.sh 来开始，而不必花费 token 去摸索如何启动服务器、配置数据库、将应用调整到可测试状态。在每次会话中节省的这部分开销，积累起来不容忽视。

其次，初始化 Agent 创建一个全面的功能列表文件。在 Anthropic 内部运行的 claude.ai 克隆实验中，这意味着超过 200 条具体的端到端功能描述，例如"用户可以打开一个新对话，输入查询，按下回车，并看到 AI 的回复"。每个功能最初都被标记为失败。

这个文件是项目的基准事实。一个开启新会话的编程agent 读取这个文件，就能立刻确定无疑地知道哪些东西已经构建完成、哪些尚未完成。它无法环顾四周，看到一些代码，就得出工作已完成的结论——功能列表会告诉它真相。

第三，初始化 Agent 创建一个 claude-progress.txt 文件并进行初始的 git 提交。进度文件是一个人类可读的日志，agent 在每次会话结束时更新它，记录自己处理了什么、完成了什么、以及将事情留在了什么状态。结合 git 历史记录，每一个后续编程 agent 都能快速定向，而无需将上下文预算耗费在考古工作上。

第二部分是编程 Agent。 初始化之后的每次会话使用不同的提示词：一次只处理一个功能，将环境留在干净的状态，并在会话结束前更新进度文件和 git 历史。增量推进，记录状态，干净交接。

功能列表作为认知锚点

功能列表值得特别关注，因为它解决了一个容易被低估的问题。没有它，在复杂代码库中运作的 agent 必须从代码本身推断项目的完成度。这种推断是不可靠的。

代码可能存在但并不可用；功能可能存在但并不完整。一个阅读代码并推断完成情况的 agent，会频繁得出错误答案，严重到足以构成问题。

功能列表使完成度变得明确无歧义。每个功能都有一个passes 字段，值为 true 或 false。 Agent 要么在端到端验证某功能可用后更新这个字段，要么不更新。没有歧义，不需要推断，基准事实就在文件里。

Anthropic 有意将这个列表存储为 JSON 而非 Markdown。原因是行为层面的。从经验来看，模型对 JSON 文件的不当修改或覆写概率，低于对 Markdown 文件的概率。

JSON 具有抵制随意编辑的刚性结构。这是一个细节，但后果真实存在：你希望功能列表是agent 谨慎更新的东西，而不是它心血来潮随意改写的东西。

{"category": "functional",

"description": "新建对话按钮创建一个全新的会话",

"steps": ["导航到主界面",

"点击"新建对话"按钮",

"验证新会话已创建",

"检查对话区域显示欢迎状态",

"验证对话出现在侧边栏中"],

"passes": false}

伴随此格式的指令是明确的：删除或编辑测试是不可接受的，因为这可能导致功能缺失或存在缺陷。你提示模型将这个文件视为不可侵犯的。 JSON 结构在架构层面强化了这一指令。

增量推进与干净状态要求

多会话 agentic 工作中最困难的问题之一，是确保每次会话结束时都处于一个下一次会话可以安全地在其上构建的状态。

若无明确的执行机制，agent 倾向于将工作留在上下文窗口填满时碰巧所处的状态：半成品功能、破损的测试、未记录的变更。下一个 agent 继承的是这团乱麻。

Anthropic 的解决方案是将干净状态作为一等要求，而非可有可无的附加项。每次编程 agent 会话以一次 git 提交（附有描述性信息）、对进度文件的更新以及在必要时回退到可工作状态为结尾。

他们所说的"干净状态"，意味着代码适合合并到主分支：没有重大缺陷、有良好文档、处于一个开发者可以合理地开始新功能而无需先解开他人半成品工作的状态。

git 提交不只是一个检查点，它是一个恢复机制。当 agent 做出破坏某些东西的变更时，它可以用 git 回退到最后已知的良好状态并重试。这正是人类工程师的工作方式，事实证明对 agent 同样是正确的纪律。版本控制是认知脚手架，而不仅仅是源代码管理。

测试：无人愿意谈论的失败模式

Anthropic 记录了一种几乎在每个认真的 agentic 编程项目中都会出现的失败模式：agent 在没有端到端验证的情况下将功能标记为完成。

Agent 会做出代码变更，对开发服务器运行单元测试或 curl 命令，看到通过结果，然后将功能标记为已完成。但当以用户方式通过浏览器测试时，该功能实际上并不可用。

单元测试成功与端到端功能可用之间的差距，是人类工程师通过切换上下文来跨越的——运行应用并尝试使用它。一个没有明确浏览器测试能力的 agent 无法完成这种切换。

它只能观察其工具所允许观察的内容，如果这些工具不包括浏览器自动化，它就会持续遗漏一类只在真实用户流程中显现的缺陷。

解决方案是为 agent 提供访问 Puppeteer MCP 服务器的能力——一个浏览器自动化工具，允许 Claude 实际导航应用、点击按钮、填写表单，并验证功能端到端可用。

性能提升是显著的。仅从代码中不可见的缺陷，当 agent 能够看到用户所见的内容时，变得一目了然。

这是一个通用原则的具体例证：agent 工作的质量受限于其反馈回路的质量。如果你的 agent 无法在真正重要的领域中观察到其行为的后果，它就会对代理指标进行优化，而这些指标可能与实际正确性并不相关。

启动流程：快速进入状态

Anthropic harness 中每次编程 agent 会话都以一套标准化的启动流程开始，其目的是在不浪费 token 的前提下尽快为 agent 定向。该流程如下：

运行pwd 确认工作目录；读取进度文件和 git log 以了解近期工作；读取功能列表并选择优先级最高的未完成功能；运行init.sh 脚本启动开发环境；运行基本的端到端测试以验证应用处于可工作状态。

只有完成所有这些步骤之后，agent 才会开始处理新功能。如果启动测试显示应用已损坏，agent 会在触碰任何新内容之前先修复已有问题。这防止了一种复合问题：agent 在破损的基础上开始新功能，使底层问题更难被隔离和修复。

启动流程还以一种具体的方式节省了 token：因为 init.sh 脚本精确记录了如何启动开发环境，agent 不需要从头摸索。每次会话在环境配置上节省的 token，在一个漫长项目中积累起来相当可观。

[助手] 我将首先确认方向，了解项目的当前状态。

[工具调用]

[工具调用]

[工具调用]

[助手] 让我检查 git log 以查看近期工作。

[工具调用]

[助手] 现在让我检查是否有 init.sh 脚本来重启服务器。

<启动开发服务器>

[助手] 很好！现在让我导航到应用，验证一些基本功能仍然正常运行。

<测试基本功能>

第四部分：OpenAI 的 Harness 工程（零行手写代码）

这场实验

2025 年 8 月下旬，OpenAI 的Codex 团队以一个唯一的约束条件创建了一个 git 代码库：无人工编写代码。代码库中的每一行代码——包括应用逻辑、测试、CI 配置、文档、可观测性工具和内部开发者实用工具——都将由 Codex agent 编写。人类负责引导，agent 负责执行。

五个月后，该代码库在上述所有类别中共包含约一百万行代码。大约 1500 个 PR 已被提交并合并。一个由三名工程师组成的小团队推动了其中大部分工作，平均每名工程师每天提交 3.5 个 PR。

随着团队扩充至七名工程师，每名工程师的吞吐量实际上还有所提升。该产品拥有数百名每日活跃的内部用户和外部 alpha 测试者。

这不是演示，而是一个完全通过 agent 生成代码构建和交付的真实内部产品。团队于 2026 年 2 月撰文描述了这段经历，其核心信息与 SWE-agent 论文一致：瓶颈从来不在模型能力，瓶颈始终在于环境设计。

工程工作的重新定义

OpenAI harness 工程文章中最重要的观察，是关于工程工作本身的变化。当你的主要工作不再是编写代码，你在做什么？

你在设计环境。你在明确意图。你在构建反馈回路。你在持续追问的不是"我如何修复这个缺陷？"而是"环境中缺少什么能力，导致这个缺陷反复出现？"

当某些东西失败时，修复方案几乎从来不是"更努力尝试"，而几乎总是"环境中缺少或配置错误了什么结构性要素，导致 agent 在这里失败？"这是工程思维的深刻转变：你不再调试代码，你开始调试产生代码的系统。

工程团队的首要工作变成了使 agent 能够完成有用的工作，而不是亲自完成这些工作。

在实践中，这意味着：将宏大目标分解为更小的构建模块，构建使这些模块可实现的工具和抽象，以及将失败作为信号，了解环境需要在哪些方面提供更好的支持。

人类工程师采用深度优先的工作方式：当 agent 卡住时，他们不会试图亲自编写代码，而是追问缺少什么，将其构建进环境，然后让agent 再次尝试。

代码库知识作为系统记录

OpenAI harness 中最重要的架构决策之一，是将代码库本身作为 agent 所需了解的一切内容的唯一真实来源。其洞察简单却意义深远：

从agent 的视角来看，任何它在运行时无法在上下文中访问的内容，实际上都不存在。存在于 Google 文档、Slack 消息线程或某人脑海中的知识，对系统而言是不可见的。

在项目早期，团队尝试了"一个大 AGENTS.md"的方案——一个单一的大型指令文件，包含 agent 需要了解的关于项目、架构、规范和约束的一切。它以可以预见的方式失败了，且以四种值得理解的方式失败。

第一，上下文是稀缺资源。一个庞大的指令文件挤占了任务、代码和相关文档的空间。 Agent 要么遗漏关键约束，要么开始为错误的目标优化。

第二，过多的指导变成了无指导。当一切都被标记为重要，就什么都不重要了。 Agent 开始局部模式匹配，而不是有意识地导航。

第三，它会瞬间腐化。随着代码库的演进，一体化手册变成了过时规则的坟场。

第四，它难以验证。一个单一的文本块不适合进行覆盖率检查、新鲜度追踪或交叉链接，漂移是不可避免的。

解决方案是一个被视为系统记录的结构化docs/ 目录，配合一个简短的 AGENTS.md 文件（约 100 行）作为地图，指向其他地方更深层的真实来源。

设计文档经过了分类和索引；架构文档提供了领域和包层次的顶层地图；计划被视为第一等制品，其进度和决策日志被提交进代码库。

这实现了团队所称的渐进式披露：agent 从一个小而稳定的入口点出发，被引导去知晓下一步该看哪里，而不是一开始就被淹没。结果是 agent 能够直接从代码库推断整个业务领域，无需访问可能不可用或可能已过时的外部上下文。

应用可读性：让系统对 Agent 可见

随着代码生成吞吐量的增加，瓶颈从生成转移到了验证。团队生成代码的速度超过了人工 QA 的验证能力。解决方案是通过让应用对 Codex 直接可读，使更多的验证工作成为 agent 能够自行完成的事情。

这涉及若干具体投入。他们使应用能够按 git worktree 启动，让 Codex 能够为它正在处理的每个变更启动并驱动一个应用的独立实例。

他们将 Chrome DevTools Protocol 接入 agent 运行时，并创建了处理 DOM 快照、截图和浏览器导航的工具。这使 Codex 能够直接复现缺陷、验证修复，并对 UI 行为进行推理，而不需要人类与应用交互。

他们构建了一套完整的本地可观测性技术栈：通过 LogQL、PromQL 和TraceQL 向 Codex 暴露日志、指标和追踪。

每个agent 任务都运行在一个完全隔离的、拥有独立可观测性数据的应用版本上，任务完成后即被销毁。这意味着agent 可以使用真实的可观测性工具调试类生产环境问题——与人类工程师使用的工具相同——而不必仅凭代码推断行为。

这里的原则与 SWE-agent 论文所论证的相同：agent 工作的质量受限于其反馈回路的质量。如果 agent 能看到用户所见的内容，并能观察到人类工程师所观察的相同指标和日志，它就能捕获并修复比仅能操作代码的 agent 宽得多的一类问题。

在不微观管理的情况下执行架构

在一个完全由 agent 生成的代码库中，随着时间推移维护架构一致性是最有趣的挑战之一。 Codex 会复制代码库中已存在的模式，包括不均匀或次优的模式。

久而久之，这会导致漂移：糟糕的模式扩散，不一致性积累，代码库对未来的 agent 运行变得更难正确导航。

OpenAI 的解决方案是机械化地执行不变量，而非依赖人工代码审查。应用围绕一个刚性的架构模型构建：每个业务领域划分为固定的层次集合，具有经过严格验证的依赖方向和有限的允许边界集合。

这些约束由自定义 linter（自然是由 Codex 编写的）和结构测试来执行。

核心洞察是执行边界，同时允许边界内的充分自由。 Linter 检查代码是否沿正确方向流经层次结构，但不规定边界内特定功能如何实现。这与平台团队在规模化时保持有效性的原则相同：执行基础，在其上允许自主。

这些 linter 是专门为 agent 生成有用错误消息而定制编写的。当 linter 捕获到一个违规时，错误消息包含格式化为可注入 agent 上下文的修复指令。这形成了闭环：被违反的约束、被违反的规则，以及修复步骤，全部在单一的可操作反馈消息中一并传递。

他们还将所谓的"黄金原则"直接编码进代码库：有主见的、机械化的规则，使代码库对未来的 agent 运行保持可读性和一致性。优先使用共享工具包而非手写辅助函数，在边界处验证数据形状。

这些原则通过周期性运行的后台清理任务来执行——扫描偏差、更新质量评级、提交针对性的重构 PR。其中大多数可在一分钟内完成审查并自动合并。

吞吐量改变了合并哲学

当 agent 吞吐量大幅超过人类注意力容量时，传统工程规范会变得适得其反。等待审查的PR 阻塞了 agent 的工作；逐一调查的测试偶发性失败消耗了本可用于更高杠杆任务的人类注意力。

OpenAI 的团队做出了一个有意为之的决定：以最小的阻塞合并门控来运作。 PR 保持短生命周期，测试偶发性失败通过重新运行来处理，而非无限期阻塞进度。

当agent 吞吐量远超人类注意力时，纠错是廉价的，等待是昂贵的。这个权衡在低吞吐量环境中看起来不负责任，在高吞吐量环境中则显而易见。

这对向 agent 驱动开发转型的团队而言是一个真正重要的洞察。当人类工程师亲自编写每一行代码时合理的合并哲学，在 agent 每名工程师每天生成 3.5 个 PR 时并不自动适用。瓶颈发生了转移，流程也需要随之转移。

第五部分：Awesome Agent Harness 分类体系

生态系统图谱

由 GitHub 上AutoJunjie 项目维护的 Awesome Agent Harness 代码库，试图绘制 harness 工程工具链这一新兴生态系统的全景图。在深入分类体系之前，有必要先明确其核心论点：AI 编写代码的能力实际上已经是一种商品。

基础模型可以生成可运行的代码，这不再是差异化能力。真正的差异化能力在于协调机制与环境设计。

该代码库将一个严肃的 agent harness 生态系统所需的完整技术栈划分为七个不同层次。理解这些层次，有助于解释为何"构建一个 AI 编程助手"实际上是许多相互独立的工程问题，而非一个单一问题。

第一层：人类监督

位于最顶层的是人类监督层，由人类负责审批提案、审查 PR、设定优先级。这在传统意义上并非一个技术层，而是人类判断与 agent 执行之间的接口。

此处的核心设计原则是：工程师应当负责设计环境、审查产出，而非直接编写代码。他们的杠杆来自于引导，而非执行。

第二层：规划与需求（Spec 工具）

这一层将人类的想法转化为结构化规格说明和任务 DAG（有向无环图），供 agent 可靠地消费执行。

其底层洞察在于：agent 是盲目执行的。如果规格说明模糊或存在歧义，agent 会按其自身的理解来产出结果，而这往往与人类的真实意图相悖。 Spec 工具在代码编写之前的需求阶段强制要求精确性。

该领域中的一个项目 Chorus，试图解决代码库所称的"反向对话缺口"。它并非让人类来撰写详细的规格工单（这是一个重大故障点，因为人类在 agent 所需的精确程度上并不擅长），而是让 AI 来提出任务 DAG 并细化需求，人类则在执行开始前扮演严格的验证与审批角色。

AI 从局部意图生成完整规格说明的能力，强于人类从零开始撰写的能力。

第三层：全生命周期平台

这类工具管理从初始需求到最终交付的端到端流程，将 AI 提案与人类验证关卡及子 agent 编排整合为一体。它们是规格层与执行层之间的粘合剂，负责处理整个开发生命周期中的状态管理。

第四层：任务运行器（Task Runners）

任务运行器弥合了问题追踪系统（GitHub Issues、Linear）与编程 agent 之间的鸿沟。其工作流如下：

由人类或 PM agent 创建 Issue，任务运行器生成工作空间，agent 交付 PR，人类进行审查。

这一类别中的工具包括：持续轮询任务队列、决定何时启动 agent、以及在无需人工介入执行循环的情况下完成工作交付的各类系统。

第五层：Agent 编排器

编排器通过在独立的 git worktree 中隔离各 agent 的工作，实现多 agent 并行执行，从而解决吞吐量问题。

这一点至关重要——如果多个 agent 并行工作时共享同一工作空间，彼此之间必然会产生冲突。 Git worktree 隔离为每个 agent 提供了独立的沙箱，使多个 agent 能够同时工作而互不干扰。

Vibe Kanban、Emdash、Composio 等工具均实现了这一模式。每个 agent 任务拥有独立的 git worktree，变更在隔离环境中得到验证后方可合并。

CI 反馈、合并冲突以及 agent 间的协调，均由编排层统一处理，无需人工干预。

第六层：Agent Harness 框架与运行时

框架提供用于构建自定义环境的可组合原语：渐进式披露机制、子 agent 生成、结构化上下文分发。运行时则提供持久化基础设施：长期记忆、定时执行、会话间多通道通信。

框架与运行时的区别至关重要。 框架是你在其上构建的东西，运行时是持续运行的东西。

Claude Agent SDK 主要是一个框架。而一个按 cron 计划运行 agent、跨会话维护持久记忆、处理 agent 实例间多通道协调的系统，则是一个运行时。两者对于严肃的长期 agentic 工作而言缺一不可。

第七层：编程 Agent

位于最底层的是执行层：Claude Code、Codex 及类似系统，负责编写、测试和调试代码。代码库的核心洞察在于：这一层是商品化的。 Agent 的有效性主要由技术栈中其上方的所有层级决定，而非 agent 本身。

这一颇具挑战性的论断有充分的证据支撑。 SWE-agent 论文通过实验验证了这一点：相同的模型，仅凭界面设计改进便带来了 64% 的性能提升。

OpenAI 的Codex 团队从实际操作层面验证了这一点：真正重要的工程工作是环境设计，而非执行本身。 Anthropic 的 harness 工程实践从实操层面验证了这一点：初始化 agent 的配置决定了编程 agent 能否顺利推进工作。

第六部分：反复出现的设计模式

纵观所有这些系统和组织，若干设计模式反复出现。这并非巧合，而是在尝试大规模可靠部署agent 时涌现出的问题所对应的工程解决方案。

模式一：渐进式披露（Progressive Disclosure）

不要预先将 agent 可能需要的所有信息一次性提供。给它定向所需的最小信息量，并提供必要时获取更多信息的指引。这一模式在以下场景中均有体现：

SWE-agent 的搜索结果上限（不返回全部结果，迫使 agent 进行精炼）、OpenAI 的 docs/ 架构（简短的地图指向更深层的内容）、Anthropic 的启动流程（先读进度文件，再读功能列表），以及实现结构化上下文分层的harness 框架。

采用这一模式的认知原因在于：上下文是有限资源，agent 的注意力并非均匀分布其间。位于提示词开头的信息具有不成比例的影响力。一个简短、聚焦的入口点，指向更丰富的上下文，比稀释注意力的大而全的信息堆砌更为有效。

实践原因在于可维护性。一个作为更深层文档地图的简短入口点，是可以保持准确的；而一个包罗万象的单体文档则会迅速变得陈旧，并产生反效果。

模式二：Git Worktree 隔离

一个 agent，一个worktree。这一模式出现在每一个严肃的编排系统中。其逻辑是直接的：当多个 agent 并行工作（或单个 agent 按序执行任务）时，需要在工作流之间保持隔离。若无隔离，并行 agent 会相互覆盖彼此的变更。

即便是顺序执行的 agent，也需要能够在隔离环境中验证变更，再将其影响扩散到主代码库。

Git worktree 在文件系统层面提供这种隔离。每个 agent 拥有独立的工作目录、独立的分支和独立的环境。

变更在隔离环境中产生、在隔离环境中测试，仅在通过验证后才被合并。这正是现代 CI/CD 系统为人类工程师所采用的模式，同时也被证明是 agent 编排的正确模型。

模式三：规格优先，代码库作为系统记录

Agent 对非正式知识是盲目的。任何存在于 Slack 消息、Google 文档或某人脑海中的信息，对 agent 而言都是不可见的。 Agent 能够处理的只有其上下文窗口中的内容，而该上下文的唯一可靠来源就是代码库。

这一模式体现为：Anthropic harness 中的功能列表文件、OpenAI 系统中结构化的 docs/ 目录、各开源框架中的 AGENTS.md 文件，以及 awesome-agent-harness 分类体系中的 spec 工具层。

共同主线是：规格说明、需求、架构决策和约束条件，必须在执行开始前编码为代码库中的机器可读文件。 如果 agent 无法从代码库中读取，它便不存在。

这对工程团队的文档工作方式具有重要含义。文档不再仅仅是为人类读者服务。它是人类意图对agent 可见的机制。模糊、陈旧或存储在代码库之外的文档，是积极损害 agent 性能的文档。

模式四：机械化架构执行

人工代码审查无法扩展到 agent 驱动的开发场景。当 agent 每名工程师每天能够提交 3.5 个 PR 时，审查不能成为维护代码质量和架构完整性的主要机制。解决方案是将架构约束编码为自动运行的机械化检查。

自定义 linter、结构测试和 CI流水线，取代了人工驱动开发中代码审查所承担的大部分功能。

机械化检查的优势在于：一致性强、速度快，并能在违规发生点提供即时反馈。一个捕捉到架构违规并在错误信息中返回修复指令的 linter，比三天后在 PR 评论中才捕捉到同一问题的代码审查者更为有效。

核心设计原则是执行不变量，而非实现细节。你深切关注的是依赖方向、边界跨越、接口处的数据校验以及命名与结构的一致性。

而 agent 使用哪个具体库、如何分解某个函数，只要满足行为契约，你并不在意。这在定义良好的结构内给予了 agent 充分的自主空间。

模式五：闭合的反馈回路

所有高性能的 harness 架构都将反馈回路收紧到极致。 linter 在编辑时捕获语法错误；运行时错误通过 agent 可查询的可观测性工具浮现；UI 缺陷通过 agent 可驱动的浏览器自动化工具发现；测试失败则附带上下文信息，说明哪里出了问题。

与之相对的另一种方式——agent 编写代码，在外部进行测试，在后续会话中才获得失败反馈——速度更慢、token 消耗更多，也更容易产生级联失败。反馈回路中每一个能够缩短行动与结果之间间隔的节点，都是可以提升 agent 性能的节点。

这是 harness 对于经典软件工程原则"尽早捕获错误"的具体演绎。错误发现得越早，修复成本越低。对 agent 而言，这一原则更具强制性——未被即时捕获的错误会在上下文中累积，并降低后续推理的质量。

第七部分：这对工程师究竟意味着什么

可迁移的技能

harness 工程这一学科，本质上是将系统思维应用于 agent 环境。它要求你对语言模型的认知架构有足够深入的理解，从而能够设计出顺应其运作机制而非与之对抗的环境。

它要求你以分布式系统工程中熟悉的方式来思考状态管理、反馈回路、错误恢复和上下文优化，只不过将其应用于一个全新的领域。

在这一新兴范式中最为高效的工程师，并不是那些拥有最佳提示词技巧的人——尽管提示词确实重要。

他们是那些理解整个系统运作方式的人：上下文如何流动、在哪里遭到污染、如何收紧反馈回路、如何跨会话保持状态，以及如何在不微观管理 agent 行为的前提下执行约束。

抽象地看，这些并非全新的技能，而是优秀软件工程师已有技能的延伸：系统设计、API 设计、错误处理、测试策略。真正新颖之处在于领域的转换：从为人类设计接口，转变为为语言模型 agent 设计环境。

你应该追问的问题

当你构建的 agent 系统出现问题时，harness 工程思维会引导出一套与朴素思维截然不同的问题。

与其问"我怎么写出更好的提示词？"不如问"agent 当前无法获取哪些它所需要的信息？

"与其问"为什么模型会犯这个错误？"不如问"缺少哪个反馈回路，导致这个错误在传播之前未能被捕获？

"与其问"agent 为什么没有按我说的去做？"不如问"环境中存在什么约束，阻止了 agent 执行我的指令？"

这种转变不只是语义层面的。它改变了你投入工程精力的方向。为某个特定故障模式设计更好的提示词，是局部的、临时的。构建能够预防一类故障模式的更好工具，是通用的、永久的。 harness 正是这种永久性投资的载体。

执行层的商品化

awesome-agent-harness 代码库核心论点中有一个令人不安的含义，值得直白地说出来。如果执行层是商品化的，那么 AI 驱动开发中的长期竞争壁垒就不在于模型本身，而在于 harness。

这意味着，那些投资于 harness 工程——构建脚手架、反馈回路、可观测性、规格工具以及使 agent 能够大规模可靠工作的编排系统——的组织和个人，将相较于那些主要专注于选择何种模型或如何提示的人，拥有持久的优势。

OpenAI 的 Codex 团队为其特定代码库和领域构建了相当于自定义开发平台的东西。 Anthropic 构建了一套 harness 架构，使其能够在复杂应用上实现数月的持续进展。 SWE-agent 团队构建了一套界面，使相同模型产出提升了 64% 的结果。这些优势没有一个来自模型本身，它们全部来自环境。

模型负责思考，harness 决定思考什么。把这个区别理解清楚，才是真正理解了这场游戏的全部。

第八部分：构建你自己的 Harness

最小可用 Harness

你不需要构建 OpenAI 的可观测性技术栈，也不需要 Anthropic 完整的双 agent 架构，就能从 harness 思维中获益。一个真实项目中针对编程 agent 的最小有效 harness，只需要少数几个核心组件。

从持久化进度文件开始。让 agent 在每次会话开始时读取它，以了解上次做了什么；在每次会话结束时写入它，以记录本次的工作。这一个单一改变，就能防止"过早宣告完成"的失败模式，并确保跨上下文窗口边界的工作连续性。

添加结构化任务列表。不是对项目的模糊描述，而是具体的、可枚举的、可验证的完成标准列表。每一项都应描述一个可端到端测试的用户可见行为，并标注状态——agent 只有在完成验证后才能更新该状态。这能防止"做了一半看起来像做完了"的失败模式。

将带有描述性提交信息的版本控制作为每次会话的一等公民。每次会话以一次提交结束。在代码提交且进度文件更新之前，agent 不应认为工作已完成。这创造了干净的交接，使多会话工作具有连贯性。

如果你在构建 Web 应用，请添加浏览器自动化。一个只能读取代码的 agent 与一个能够实际使用所构建应用的 agent，其差距，等同于一个只能读代码的开发者与一个能够运行应用的开发者之间的差距。大多数真正重要的 bug，只有在运行时才能显现。

环境审计

如果你已有一套 agent 系统但表现欠佳，harness 工程方法建议采用一套特定的诊断流程。不要急于寻找更好的模型或更长的提示词，而是做一次环境审计。

追问：agent 需要哪些它目前无法获取的信息？在任务流程中，agent 经常在哪些节点卡住或犯错？缺少什么反馈，导致 agent 无法自行捕获这些错误？上下文在哪里被无关信息污染？有哪些约束目前依赖 agent 的自我判断来执行，而应当被强制检查所取代？

每一个问题都指向一个具体的 harness 改进方向。信息缺失，变成代码库中的新工具或新文档；反馈缺失，变成新的测试、linter 或可观测性集成；上下文污染，变成新的上下文管理策略；未被执行的约束，变成新的机械化检查。

这是 harness 开发的良性循环：每一次失败都是环境需要改进的信号，而每一次环境改进都会降低该失败在未来所有 agent 会话中出现的频率。

最后一件事

变革性技术在早期阶段被误读，往往存在一个共同的规律。吸引公众眼球的东西——原始能力、令人印象深刻的演示、跑分成绩——鲜少是决定长期胜负的因素。基础设施层、harness、环境，通常才是真正价值被创造和捕获的地方。

Web 的变革性，不在于 HTML 的存在，而在于搜索引擎和浏览器让 Web 变得可导航。移动端的变革性，不在于智能手机的存在，而在于应用商店和开发者工具使得大规模地在智能手机上构建应用成为可能。在这两个案例中，组织和整合底层能力的平台层，才是持久价值的所在。

AI agent 正在遵循同样的规律。能力已然存在。问题是谁来构建让这种能力变得可靠、可控、持续可改进的环境。

SWE-agent 的研究者在 2024 年理解了这一点，并用数据加以证明。 Anthropic 在构建 Claude Code 时理解了这一点，并公开记录了下来。

OpenAI 在构建其内部产品时理解了这一点，并分享了相关经验。 awesome-agent-harness社区正在数十种工具和框架中对此进行系统性整理。

harness 就是一切。  模型是推理引擎，harness 是上下文、约束、反馈回路、记忆、工具和脚手架——它们共同决定推理引擎究竟能够完成什么。

把 harness 做对，不是一个提示词工程问题，而是一个系统工程问题。这是当前应用 AI领域最重要的工程问题。

请以此为指引，去构建。