에이전트 엔지니어링은 먼저 컨텍스트와 센서를 강화합니다.

요즘 하네스 엔지니어링에 대한 토론 그룹을 보면 가장 직관적인 느낌은 "에이전트가 새로운 기능 계층을 추가했습니다"가 아니라 엔지니어링 토론의 초점이 변경되었다는 것입니다. 과거에는 모델이 충분히 강력한지 자주 질문했습니다. 이제 우리는 먼저 얼마나 많은 컨텍스트를 넣어야 하는지, 규칙 파일을 얼마나 오래 넣어야 하는지, 센서가 어떤 신호를 보내는지에 초점을 맞춥니다. 모델은 아직 중간에 있지만 실제로 안정성을 결정하는 것은 외부 하네스입니다.

컨텍스트 창이 클수록 주의 집중이 더 안정적입니다.

수련회에서 누군가는 agents.md를 200라인 이하로 제어해야 한다고 언급했습니다. 이 숫자는 가식적이거나 행 번호 숭배가 아니라 예산 알림에 더 가깝습니다. 컨텍스트 창이 클수록 더 많은 콘텐츠를 담을 수 있다는 의미일 뿐, 파악해야 할 부분을 모델이 더 안정적으로 파악한다는 의미는 아닙니다. 모델은 컨텍스트의 작은 부분에만 초점을 맞추는 경우가 많으며, 나머지 콘텐츠가 창에 있더라도 전체 내용에 초점이 맞춰지지 않을 수 있습니다.

이것은 엔지니어링에서 매우 성가신 일입니다. 규칙이 많을수록 "제약"을 "노이즈"로 작성하는 것이 더 쉽습니다. 지침이 길수록 실제로 관찰해야 할 내용을 구석에 묻어두기가 더 쉬워집니다. 파일을 매우 짧게 유지하는 것은 문서를 깔끔하게 보이게 만드는 것이 아니라 제약 조건을 강제로 표시하는 것입니다. 모델이 직면한 것은 백과사전이 아니라 제한된 운영 계약이다.

센서가 로그를 다시 피드하지 않습니다.

또 다른 분명한 변화는 논의가 계산 센서로 옮겨가기 시작했다는 것입니다. 여기의 센서는 단순히 묻혀 있지 않으며 시스템 로그도 모델에 그대로 삽입되지 않습니다. 그러나 런타임 상태는 소수의 사용 가능한 신호로 압축됩니다. 그것이 하는 일은 소음을 걸러내는 것이지, 새로운 상황적 부담을 만들어내는 것이 아닙니다.

이것이 "Python 대신 Rust로 전환"이라고 말하는 이유입니다. 초점은 언어의 편을 드는 것이 아니라 통제에 있습니다. 센서가 품질을 보장하기 위해 런타임 경계, 리소스 제약, 예외 경로 및 결정론적 출력에 의존하면 언어 및 실행 환경은 더 이상 단순한 구현 세부 사항이 아니라 센서 자체의 일부입니다. 신호가 불안정하면 모델이 아무리 강하더라도 불안정한 입력에 대해서만 추측하게 됩니다.

원시 데이터를 모델에 직접 보내는 것이 단기적으로는 더 많은 정보를 제공하는 것처럼 보일 수 있지만 장기적으로는 장면을 더 복잡하게 만드는 경우가 많습니다. 정말 유용한 센서는 먼저 "무슨 일이 일어났는지"를 몇 가지 명확한 상태로 압축한 다음 어떤 세부 사항을 사람에게 남겨두고 어떤 세부 사항을 도구에 남겨야 하는지 결정해야 합니다.

하네스의 역할은 세계를 모델에 제공할 수 있는 조각으로 자르는 것입니다.

이러한 종류의 논의가 성숙해지면 신속한 기술보다는 시스템 설계에 더 가까워 보이기 시작합니다. 하네스는 경계(컨텍스트에 들어가는 것, 컨텍스트에서 벗어나는 것, 모델이 의존할 수 있는 상태, 도구로 재확인해야 하는 상태)를 담당합니다. 그것은 껍질이 아니라 필터와 더 가까운 층입니다.

이는 Agent 시스템에서 가장 과소평가된 비용이기도 합니다. 모델 교체는 빠르지만 하네스는 액션 체인, 시그널 체인, 실패 체인을 직접 바인딩하기 때문에 훨씬 느립니다. 컨텍스트 예산, 센서 설계, 권한 경계, 대체 경로는 모두 궁극적으로 이 계층에 속합니다. 이 계층이 단단하지 않은 한 모델이 강할수록 시스템이 불안정성을 더욱 확산시키기 쉽습니다.

지금 이러한 유형의 조각을 보면 가장 가치 있는 부분은 단일 결론이 아니라 프로젝트의 초점을 명확하게 명시한다는 것입니다. 에이전트는 더 이상 "일을 할 수 있는지 여부"가 아니라 "외부 시스템이 관심과 신호를 수집했는지 여부"입니다. 이 단계는 안정적이지 않으며 모델 기능이 더욱 향상되면 혼란이 더 빠르게 증폭될 뿐입니다.